Boris,
Thanks much for the info. I was wondering if you could help clarify a
few issues, below...
> Mozilla will do progressive rendering. As far as I know, so will IE.
> I'm not sure about other browsers (this is not to imply that they do
> not; I simply have no information).
OK. I take it this is default behavior, that doesn't require anything
in the HTML other than a <table> tag, right?
>
> > (2) What else makes tables evil (if they still are) from *just a
> > performance standpoint*? Is page reflow, etc. that much more
> > processor-intensive using tables than with CSS
>
> It is quite possible to create tables with CSS ("display: table" and the
> like). In Mozilla's implementation, these share all the problems of
> HTML tables.
>
> The major problem with table layout (again, in Mozilla, but this part
> applies to all browsers to some extent) is that, unlike most of reflow,
> it absolutely requires two passes to get right (due to the shrink-wrap,
> auto-size nature of table reflow). This is two passes for the table.
> Now if you have a nested table, you get two passes for the outer table
> and for each one you get two passes for the inner table, etc. One can
> put in some optimizations to make the number of times the inner table is
> reflowed not grow exponentially, but these optimizations themselves take
> some processing time.
Makes sense. Any idea what happens in the first pass, vs. the second
pass? I want to make sure I understand what you mean by 'shrink-wrap
/ auto-size'
>
> > so much so that it would affect a general user's web experience,
> > perceived page load times, etc?
>
> This part depends heavily on the hardware, bandwidth, etc.... I do not
> have a useful answer (perhaps someone else does?).
>
> > Do fixed widths on tables significantly help/hinder things
>
> They can significantly help things when combined with table-layout:fixed
> (whenever practicable). Fixed widths on tables that are overconstrained
> (eg setting a table to 200px and having two cells inside each set to
> 120px) hinder things a bit as things have to get reshuffled.
Thanks, now that you pointed this out, I've been able to find a fair
amount of documentation to back this up. Out of curiousity, what
exactly happens when a fixed-width table is over-constrained in
Mozilla? Does it display the incorrectly-sized table as it's working,
and then redisplay it properly -- or does it re-render the table from
square 1 before displaying anything to the scree?
>
> > (3) Knowing how browsers work, what else would you preach to web
> > developers to make for a snappier web, today and tomorrow?
>
> table-layout:fixed is a big one, again when possible.
>
> One suggestion I would make is to defer all JS loading until as late as
> possible. The reason is that when a browser encounters a <script> tag
> it must halt the HTML parser (modulo the "defer" attribute), fetch the
> script from the network, parse it, execute it, and only then restart the
> HTML parser. Thus if you have a script that you don't really need
> that's fetched externally, eliminate it. If you need it but not till
> onload, moving the load to the end of the page may show more of the page
> faster (while slowing down overall load time, possibly, as the script
> load is kicked off later).
I'll include this. BTW, what about HTTP1.1 support -- though it's not
something that is enabled via HTML, it does seem like something folks
could request of their sysadmin... is HTTP1.1 new in Mozilla / Nav6,
or was it in the 4.x release, too?
Again, thanks for your help!
-Jason
