- From: Steve Clark <buster@netscape.com>
- Date: Thu, 10 Feb 2000 11:01:29 -0800
- To: Matthew Brealey <thelawnet@yahoo.com>
- CC: www-style <www-style@w3.org>
right. the mozilla engine lays out the table as data is recieved, as long as that data is consistent with the column widths computed after the first row. then, when inconsistent data is encountered, mozilla has to throw out it's work up to that point and start over with the new column width values. it's really no different than if a fully specified table were fully loaded, and then somebody added a cell onto a row using the DOM. so in the case you presented, the incremental loading advantage is lost, and using "table-layout: fixed" wasn't a good choice for this table. in the normal case, though, where all column width data is available after the first row, the table was rendered in approximately half the time (and sometimes much better than half!) it would have taken for normal table layout. I'm pretty sure this is in the spirit of the spec. If you're arguing for tightening up the language, that's great. If you're arguing that the spec is fundementally flawed, I don't see that yet in this discussion. Steve Clark Matthew Brealey wrote: > --- Steve Clark <buster@netscape.com> wrote: > [snipped spec quote] > > > In this manner, the user agent can begin to lay out the table once the > > > entire first row has been received. > > > </blockquote> > > > > > > Really? > > > > sure. > > > > In mozilla, fixed table layout does the right thing with the data it has > > available. If at any time it encounters data that invalidates the > > constraints > > already computed, it simply recomputes (that's a gross approximation, > > there are > > all kinds of performance enhancements in there.) So, the effect is the > > table > > is laid out on a "best-effort" basis with partial data. If the author > > has > > specified a reasonable table, one in which all column widths are > > computable > > from info in the first row (at worst), then the author gets the one-pass > > performance they intended. If they don't specify the data correctly, > > they get > > degraded performance but still get correct layout according to the fixed > > table > > layout algorithm rules as if the total number of columns were known > > initially. > > Indeed. I actually ran this example through Mozilla before posting (half > expecting a crash), but I still don't see how it can lay out the first row > after receiving it. > > For example: > <table border style="table-layout: fixed; width: 100px"> > <tr> > <td> > Cell > <td> > Cell > </table> > > If it lays out that row (as the spec claims one can do), you get: > ----------|----------| > |Cell | Cell | > ---------------------| > | | > |--------------------| > 100 pixels wide > > Now if when we get to row 999999, we get: > <tr> > <td> > Cell > <td> > Cell > <td> > Cell > , then our incremental rendering thus far is: > ----------|----------| > |Cell | Cell | > ---------------------| > ----------|----------| > |Cell | Cell | > ---------------------| > > If we try and stick this row on, we get: > ----------|----------| > |Cell | Cell | > ---------------------| > ----------|----------| > |Cell | Cell | > ---------------------| > ----------|----------|----------| > |Cell | Cell |Cell | > |---------|----------|----------| > > Any browser that has chosen, as the spec suggests, to render the rows as > it receives them is in something of a quandary because its layout is > messed up. > > Certainly one-pass rendering is possible, but this kind of incremental > rendering does not seem to be so. > > ===== > ---------------------------------------------------------- > From Matthew Brealey (http://members.tripod.co.uk/lawnet (for law)or http://members.tripod.co.uk/lawnet/WEBFRAME.HTM (for CSS)) > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com
Received on Thursday, 10 February 2000 13:58:34 UTC