Print

Print


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.

Ethan Gruber
University of Virginia Library

On Sun, Sep 6, 2009 at 12:01 PM, Joyce Chapman <[log in to unmask]>wrote:

> 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?
>
> Joyce
>
> --
> Joyce Chapman
> NCSU Libraries Fellow
> Metadata and Cataloging/
> Digital Library Initiatives
> [log in to unmask]
>