Re: the time load-rendering order

> My feeling is that this would be taking styled HTML well
> beyond what it is appropriate for.  HTML was designed as
> a navigation tool for finding more specific formats, not
> as a multimedia animation and page description language.

Yes, could fit better on CSS in the rendering part, but on HTML on the
loading-importance.... And, ejem, let me remember you that a mouse was not
initially God designed for eating cheese, and not to say Microsoft
IntelliXploter.

> (something I never really understand is why people put in
> so many cosmetics when for most of the time that a navigation page
> is on display it is incomplete, and therefore ugly).

Problably because they don't use to take a look at an habitual browser
rendering of their pages in a very slow connection. Here's where a object
load order should make sense.

> Accessibility considerations, and the effect of caching, mean that
> you cannot rely on images, or their order of presentation,
> to convey critical information.

Critical information depeds strongly of the intended audience and his
expectations. If your intended audience needs images you should give them in
the better conditions that you can. The rest of audience are supposed to be
prepared to expect nothing special, so only problem is assuring
compatibility.
Obviously, for same reasons, you would never rely on HTML or their tags to
convey critical information for a plain/text mail audience.

Images are very important, and their order of importance and the importance
of their order will grow. Try to figure out why some people's minds not so
long time ago were going to cinemas everywhere to view the famous "structure
vs presentation" thriller.

> Also note that HTTP 1.1 clients are supposed to only maintain
> two connections at a time, so will display images in succession,
> and probably in the linearised order of the page.
>  In fact,
> pipelining of requests will mean that maybe up to thirty image
> requests will already have been issued by the time the end of the
> HTML is reached, so any display me first image at the end will have
> to wait for all the images in the pipeline, or no requests can be
> made until the whole page has been read, or the pipeline will have
> to be aborted and restarted.

Browsers can detect when a connection is going slow, in such cases should be
normal to give preference to certain objects between others. The case is
that browser has no idea of what author gives importance when the subject of
importance is an HTML object element.

Note too that only in a loading strict policy, the browser will wait to load
entire document before starting object request.

> > this allows more *interesting* control
> >
> [DJW:]  I suspect you should be looking at
> SMIL and or SVG, or proprietory animation formats.
This languages have many inconveniences, the most important, perhaphs, is
that their corresponding w3 mailing list's are not affected of the
"excessive postings to the list" users problem.

Personally, I prefer "packet excesive fragmentation" VS "excesive
fragmentation of programming languages", still I understand that modularity
is not only needed but fundamental. But let me copy this
(http://www.w3.org/TR/html401/appendix/notes.html#h-B.6.2) paragraph, about
forms:

(...)there is still room for many possible improvements:
(...) tabular data entry, sliders or multiple page layouts (...)

Received on Tuesday, 20 February 2001 14:39:03 UTC