The largest flaw in the older nested table approach that we see in EAD cookbook, I think, is the fact that that the HTML version of the finding aid is inflated to 400-500% of the filesize of the source XML file. This is especially evident in larger, complex finding aids that have six or more component levels. A manageable 2MB XML file transformed into a completely unusable 8MB HTML file.
University of Virginia Library
Probably many of us have been told by Web folk that a <dsc> output using empty table cells as a mechanism to control display (forcing indentation) is bad. Not only does it fail to use tables the way they are meant to be used (only as a mechanism to code tabular data, not for design/layout) but I've been told that all these empty padding cells are unfriendly to screen readers for the blind. In fact, I've been told that if you are funded with state money, you are required to be accessible to screen readers and definitely shouldn't be displaying the <dsc> info this way. I deal with this by outputting the tabular data of the <dsc> in a table with only two columns (and since it IS tabular data, 1-2 container columns and 1 content column are supposedly ok), and controlling indentation of embedded components in the content column with CSS. Which is easier for my brain to deal with than the many-columned approach anyway! So my questions:
1. How many of you are outputting the <dsc> without using a <table> at all?
2. How many of you are using a 2- or 3-column table with CSS to control embedded components?
3. How many of you have been told by your Web peeps that the many-columned approach should not be used?
NCSU Libraries Fellow
Metadata and Cataloging/
Digital Library Initiatives
[log in to unmask]