Re: FW: Preload for <section>

In terms of the specific case of a temporary replacement for bandwidth
hogging multimedia, there is already an adequate HTML mechanism:  OBJECT.
However, putting "Loading..." as the innermost content of an OBJECT would
not be considered good practice - the time fill should be the text that
is used for browsers that cannot handle the object type at all.  Disabling
the use of the innermost fallback text is a style sheet requirement, though.

However, thinking more generally, there are reasons why designers may 
want to defer the rendering of actual HTML structures, although, not
necessarily, good ones (I think the design ideal should be to start
rendering early and continue rendering progressively):

1) They may not want the user to use the the material before it is completely
   rendered.  Two sub-cases that I can think of are:

   a) forward references, e.g. when people try to simulate tabbed dialogues
      and they don't want their script triggering until the tab contents is
      available.

   b) there is critical information, such as legal notices, that should be
      available before the user takes an action.

2) Where the page includes dynamic content that takes time to generate on
   the server, the designer may think that the initial display of page 
   headings may lead the user to believe that the page is already complete
   (although people must be getting used to a similar effect from non-
   incremental tables).

3) Annoying behaviour as the browser backtracks and takes account of exact
   image sizes, font metrics specified in style sheets, downloaded fonts,
   display suppression in external style sheets, etc.

4) A desire not to let the user see the painter algorithm nature of the build
   up of the image, possibly in association with attempts to (mis-)use 
   scripting of HTML for animation, rather than use something designed for
   animation.

Given the example in 1(a) assumes a good CSS positioning implementation, I
tend to feel that the right way is to leave a gap for the tabs and back 
fill when the the contents of the tab, or of all tabs, has been sent.  There
may be issues due to the limitations of positioning.  I'd suggest most forward
references are avoidable.

I'd argue, for 1(b) that, if information is really important, it should
be presented before the control - that's the only sensible order for
speech readers, anyway.

This suggests that there may be more than one level of partial.

One might be forward only rendering, in which rendering is stalled if
there is any potential to backtrack (although one might argue that some sorts
of backtracking may be tolerable, in some contexts, but not others - e.g.
one might want to stall until an image size is known, but not mind about
a back fill of the image content).

Another might be a complete deferral until all necessary data for the whole
element is available.

Yet another might require an off-screen buffer (this one seems to assume 
GUI type rendering, but it would be nicer if one could generalise the 
concept) in order that there be no rendering artefacts, other than the
fast wipe as the area is copied onto the screen.

Received on Sunday, 29 September 2002 16:48:06 UTC