Hi Michelle-

The main problem with HTML tables is that the entire <table> must be 
processed before the browser will display it.  I think many of us who 
based our stylesheets off the original cookbook stylesheets are in this 
position for these types of files.  Many modern browsers and *all* 
mobile browsers choke on large HTML tables.   Some mobile browsers won't 
render them at all.  There's really no good reason to use them anymore 
because CSS can handle this positioning much more efficiently.   I'm 
currently working on a "proof of concept" CSS that will work in both 
regular and mobile browsers.  The following file is 4.2 MB and comes out 
to 569 printed pages.  It's one of our largest finding aids, but this 
CSS renders pretty quickly and it works in mobile browsers.   View the 
source to see how CSS affects positioning.   It still needs work and 
tweaking, but the proof of concept is there: that you can render large 
amounts of data quickly and efficiently.

I hope this helps.

Mark Carlson
UW Libraries, Seattle, WA

On 11/12/2013 7:36 AM, Michele R Combs wrote:
> Hello collective wisdom --
> We have two EAD-encoded finding aids whose size is causing problems for some patrons -- their browser locks up or otherwise fails to load the file.  We don't render on the fly; we create static HTML files.  The problem is partly file size (one is 3.4M and the other is 5.8M), and partly that the inventory section is a ginormous HTML table (yeah, I know) which takes a lot to render and load in the browser.
> We've come up with a number of options, none of which I feel are ideal, so I'm curious if others have encountered this, how you chose to handle it, and what if any impact it had on search/discovery.
> Michele
> +++++++++++++++
> Michele Combs
> Lead Archivist
> Special Collections Research Center
> Syracuse University Libraries
> 315-443-2081
> [log in to unmask]