HTML 'smudging' defined - a useful term:
> The discussion concerns rendering time, not transfer time.
The two are intimately intertwined, even in threaded browsers.
Consider a page whose entire content is nested in a complex table. The
page cannot be rendered until the entire table loads in so that sizes
can be estimated or layout can be carried out; dynamic on-the-fly
rendering in parallel with transfer time is not possible, and the
rendering time becomes dependent on the time taken to finish transfer.
The exact opposite is a stream of unannotated ascii text, which
appears just as it loads in over the network.
Table-based layout is bad. To wit:
- slashdot.org (which has no navigation metaphor to speak of to boot,
and dynamic cgi serving that accentuates table slowness. Boy, this
site needs a critique by someone who will then justly get lots
of publicity from the Slashdot Effect).
- mozilla.org (not anywhere as bad, but a design that is being
increasingly emulated elsewhere, increasingly badly.)
- A whole host of other poor sites whose creators would think that
having users waiting staring at a blank screen until
the bottom of the document (that won't even be visible on-screen)
has loaded in makes for cool design if they ever actually used
a modem - which they obviously don't.
The pointless (fixed-width, yet!) tables added to give a white border
around the Florida Today Space Online site are a good example of the
Table layout has replaced leaving out IMG height and width tags as the
#1 HTML cause of perceived web slowdown due to rendering/transfer
dependencies. They're worse than multi-load non-nested framesets and
far more prevalent. Their use is encouraged because enough nested
tables might just crash the other guys' browsers - that seems to be a
goal of gecko development, judging from screenshots.
[quoted nonsense about "streams", "re-evaluation", SQL and ASP
is seeing Don Norman speak at Surrey Wednesday night, incidentally.
But that will be rather more abstract than this.