table-layout "fixed" gets buffered in IE?

[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.

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.freundl...ixedTable.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

[Grant Smith - eNVENT Technologies]

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

[Adrienne]

Gazing into my crystal ball I observed "Rob Freundlich"
<ro*@freundlichs.com> writing in news:Zv********************@comcast.com:

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.freundl...ixedTable.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

[Adrienne]

Gazing into my crystal ball I observed "Rob Freundlich"
<ro*@freundlichs.com> writing in news:Zv********************@comcast.com:

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.freundl...ixedTable.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

[rob]

Adrienne wrote:

Gazing into my crystal ball I observed "Rob Freundlich"
<ro*@freundlichs.com> writing in
news:Zv********************@comcast.com:

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