Click here to get back home

table-layout "fixed" gets buffered in IE?
 Home | NewsGroups | Search | About
Login Password
Register Now!
 comp.infosystems.www.authoring.html    Post an article   get this group's latest topics as an RSS feed add this group's latest topics to your My MSN content add this group's latest topics to your My Yahoo content
Subject Author Date
table-layout "fixed" gets buffered in IE? Rob Freundlich 05-22-2005
Get Chitika Premium
Posted by Rob Freundlich on May 22, 2005, 2:51 pm
Please log in for more thread options

I have some servlet-generated tabular data that I need to present, so I'm
using an HTML Table. In some cases, it can be quite large. I'm flushing
the servlet output every N lines to push the data to the browser as it
generates, and I've used "table-layout: fixed" for the table's CSS class.

It works pretty well in Netscape (7.1 and higher) - the table is drawn
pretty much as the rows are received by the browser. However, Internet
Explorer 6.0 seems to draw the table at whim rather than as the rows are
received. Since there may be significant chunks of time between whims (or
worse, before the first draw), it looks like my app isn't responding even
though it's really IE that's the holdup.

My understanding of fixed table-layout is that it permits the browser to
draw the rows as they're received, where auto table-layout requires all rows
to have been received to allow column calculations. So I'm expecting to see
the Netscape-style behavior I described above. I've defined a width for the
table and for each column, so I'm pretty sure fixed layout isn't being
short-circuited down to auto. I've also seen that in a large table, I
*will* get chunks at a time, which implies IE isn't doing "auto" behavior.

So my assumption is that the IE code is doing a fixed layout but is
buffering for some reason, but that's just a guess.

I've distilled the situation down so that I can demonstrate it with a small
(2-row) table:

http://home.comcast.net/~rob.freundlich/css/fixedTable.html

I've injected (for debugging only - not for the final app) a javascript
alert() between the two rows to put a pause into the rendering so that I can
see when things are being drawn. In Netscape, when the alert pops up, row 1
has been drawn and is visible to the user. In IE, when the alert pops up,
neither row has been drawn.

Can anyone offer advice? I'll take CSS hacks, IE-specific JavaScript that
will force the draw, or even sacrificial rituals (yes, I'm willing to dance
widdershins around Redmond in the light of the full moon if that's what it
takes!), as long as I can fix the problem for IE6.0.

Rob Freundlich
"Males ae biologically driven to go out and hunt giraffes." - Newt Gingrich
"Some folks you don't have to satirize, you just quote 'em." - Tom Paxton



Posted by Grant Smith - eNVENT Technolog on May 29, 2005, 7:25 am
Please log in for more thread options

Rob Freundlich wrote:
>(yes, I'm willing to dance widdershins around Redmond in the light of the full
moon if that's what it
> takes!)
>
>
I don't know anything about your problem, unfortunately.....

But dancing widdershins around Redmond in the light of the full moon may
give ol' Bill a laugh or two...

--
Grant Smith
A+, Net+, MCP x 2

eNVENT Technologies - www.envent-tech.com

Posted by Adrienne on May 29, 2005, 8:01 am
Please log in for more thread options


Gazing into my crystal ball I observed "Rob Freundlich"

> I have some servlet-generated tabular data that I need to present, so
> I'm using an HTML Table. In some cases, it can be quite large. I'm
> flushing the servlet output every N lines to push the data to the
> browser as it generates, and I've used "table-layout: fixed" for the
> table's CSS class.
>
> It works pretty well in Netscape (7.1 and higher) - the table is drawn
> pretty much as the rows are received by the browser. However, Internet
> Explorer 6.0 seems to draw the table at whim rather than as the rows
> are received. Since there may be significant chunks of time between
> whims (or worse, before the first draw), it looks like my app isn't
> responding even though it's really IE that's the holdup.

Can you break up the data a bit? Maybe page the records. Usually, when I
have a lot of data, I page at 50 records.

>
> My understanding of fixed table-layout is that it permits the browser
> to draw the rows as they're received, where auto table-layout requires
> all rows to have been received to allow column calculations. So I'm
> expecting to see the Netscape-style behavior I described above. I've
> defined a width for the table and for each column, so I'm pretty sure
> fixed layout isn't being short-circuited down to auto. I've also seen
> that in a large table, I *will* get chunks at a time, which implies IE
> isn't doing "auto" behavior.

That's IE for ya. Perhaps MS just thought no one was ever going to have a
really big table, so they aren't honoring the spec.

>
> So my assumption is that the IE code is doing a fixed layout but is
> buffering for some reason, but that's just a guess.
>
> I've distilled the situation down so that I can demonstrate it with a
> small (2-row) table:
>
> http://home.comcast.net/~rob.freundlich/css/fixedTable.html

No DOCType declaration. You might want to use that and see if IE responds
any better (I doubt it).

>
> I've injected (for debugging only - not for the final app) a javascript
> alert() between the two rows to put a pause into the rendering so that
> I can see when things are being drawn. In Netscape, when the alert
> pops up, row 1 has been drawn and is visible to the user. In IE, when
> the alert pops up, neither row has been drawn.
>
> Can anyone offer advice? I'll take CSS hacks, IE-specific JavaScript
> that will force the draw, or even sacrificial rituals (yes, I'm willing
> to dance widdershins around Redmond in the light of the full moon if
> that's what it takes!), as long as I can fix the problem for IE6.0.

The only thing I can think of is to break up the data. If you have 4
columns, 50 rows; 10 columns, 25 rows, etc. Additionally, consider the
content in the table. Are you going to have images, several lines of text
in a cell? It would probably be easier for the user as well if the records
were broken up.

If most of your visitors are using IE, then you may have to live with it.

--
Adrienne Boswell
http://www.cavalcade-of-coding.info
Please respond to the group so others can share


Posted by rob@freundlichs.com on June 1, 2005, 6:54 am
Please log in for more thread options


Adrienne wrote:
> Gazing into my crystal ball I observed "Rob Freundlich"
>
>> I have some servlet-generated tabular data that I need to present, so
>> I'm using an HTML Table. In some cases, it can be quite large. I'm
>> flushing the servlet output every N lines to push the data to the
>> browser as it generates, and I've used "table-layout: fixed" for the
>> table's CSS class.
>>
>> It works pretty well in Netscape (7.1 and higher) - the table is
>> drawn pretty much as the rows are received by the browser. However,
>> Internet Explorer 6.0 seems to draw the table at whim rather than as
>> the rows are received. Since there may be significant chunks of
>> time between whims (or worse, before the first draw), it looks like
>> my app isn't responding even though it's really IE that's the holdup.
>
> Can you break up the data a bit? Maybe page the records. Usually,
> when I have a lot of data, I page at 50 records.

I might be able to break it up in some cases, but not in others. The
app is
a report generator which allows nesting of reports. The problem is
worse
than I described above (and than in the example I posted) because in
the
case of a nested report, my table structure looks like this:

Table
Row 1 - data about first record in main report
Row 2 - nested report about first record in main report,
containing:
Table
Row 1 - data about first record in nested report
Row 2 - data about second record in nested repor
...
Row 3 - data about second record in main report
Row 4 - nested report
...

The case that made me aware of the problem was when "main report" had
only 5
records, but the first one's nested report had many many records. I
think
the nested table confused IE even more than a flat table - it didn'
render
*any* of the rows in the nested table in Row 2 (above) until all had
been
received. So although breaking up the main table might help, I don't
think
that breaking up the nested table would help.

I can try it though, and see what happens. It'll require better
handling of
column widths than I have currently, since I want it to look like a
single
table to the user (i.e. the columns must match across table breaks),
but I
need that anyway.

Carried to the extreme, your suggestion would, of course, lead to a
single
row per table, in which case I might scrap tables and just use SPANs
inside
of DIVS, with widths (or CSS classes) assigned to each. I know that
will
work, but rejected it because of the overhead of giving the
widths/classes
for every element. I like your suggestion, which works out to a sort
of
middle solution - I have to emit width control periodically (i.e. for
every
table), but not nearly as frequently as in the non-table solution.

I'll give it a shot. Thanks!

--
Rob Freundlich
"Males ae biologically driven to go out and hunt giraffes." - Newt
Gingrich
"Some folks you don't have to satirize, you just quote 'em." - Tom
Paxton



Similar ThreadsPosted
2 layers fixed background ? July 17, 2004, 5:20 pm
How to keep the table a fixed size December 8, 2004, 8:59 pm
fixed table cells January 23, 2007, 11:40 pm
fixed image size February 12, 2007, 1:53 pm
fixed width and bold October 18, 2008, 4:12 pm
fixed background image w/css problem September 27, 2004, 9:29 pm
position:fixed slows Mozilla March 9, 2005, 5:53 pm
Fixed length page / scrolling div September 18, 2005, 1:12 am
3 column css layout with the middle fixed February 17, 2006, 4:32 pm
table-Layout:fixed; ok for IE but not for FireFox June 11, 2008, 5:22 am

Our other projects:

Art Dolls, Fairies and Mermaids - Sunnyfaces.net

Roy's Linux, Programming and Search Engines messages

1-Script XML SitemapXML Sitemap