Re: XHTML Applications and XML Processors [was Re: xhtml 2.0 noscript]

"Mark Birbeck" <mark.birbeck@x-port.net> wrote in message 
news:640dd5060608021435i674ae346s3678ef39720f7995@mail.gmail.com...

> What has 'idealism' got to do with it?

You're looking for absolute interopability in something that is a tiny edge 
case that is irrelevant to any real web-application, no author is going to 
be author something that relies on a particular odd behaviour of exactly 
when a script executes during loading.  This is idealistic interopability as 
it's irrelevant to the real world of authoring, and the only solution is 
much more harmful than the damage done by non-interopability - the sort of 
interopability you're looking for is similar to say pixel identical 
rendering where we don't have interopability, it's not worth the cost of 
interopability.

> Standards are by their nature
> idealistic, and not just in the utopian sense

Standards are not idealistic, they would be if they attempted to standardise 
everything, but of course no standard does that, it only standardises what 
is relevant to be useful, and doesn't impose a particular world view on 
others where it isn't helpful, banning script from operating until post load 
(please correct me if that's not your suggestion here) will simply lead to 
less useful webpages.

> I don't understand why you say that? You can't modify it during the
> load sequence, but you could modify it after that. Or are you saying
> that you couldn't make use of some input from a user until the whole
> of the document was loaded.

I'm saying if you cannot change the value of an input until after the 
document has loaded, a user interface is impossible to correct, let's 
imagine a connection that takes 1 minute to download a page (not 
unreasonable, I'm using a GPRS connection right now). The first few bytes 
contain (amoungst other things)

1 + <input id="a" value="1"> = <input id="b" value="2">

And there is script on the page such that if the user changes either the a 
or b value, the other updates to reflect the change.  This is available 
within the first 10 seconds.  The user now has 50 seconds to interact with 
this input, if the script cannot change the document until the end, then the 
user is seriously harmed, the interface doesn't work for 50 seconds, and it 
behaves differently after 50seconds, the script may be suddenly consistent 
between browsers, but it is no longer consistent between users.

> That's probably true, but I don't think
> that ruins the web at all, and there are umpteen solutions, including
> reducing the size of the initial document and then incrementally
> loading further parts,

Tiny documents and then loading more data through scripting or other method? 
That is not the way to an accessible, usable or easy to maintain web.

>> As idealistic as you are wanting to be that is not compatible with user
>> experiences required today, unless there's nothing in the initially 
>> loaded
>> document and everything is added with script to give the required user
>> experience, that would be a retrogade step.
>
> I don't understand this either. Why do you think we should have an
> empty original document, and add everything through script?

You just advocated the very same thing above!

"reducing the size of the initial document and then incrementally loading 
further parts, "

Of course you've only said reducing the size of the initial document, but 
what's more reduced than an empty one?

> I'm not
> seeing why you think that standardising on the processing model for
> XHTML documents would introduce this requirement.

It wouldn't, but a processing model that said no scripts can modify a 
document until the document has loaded would lead to that result.

> I think you might have missed the point of my discussion. The biggest
> example I gave was actually the <img> tag, and I raised the point
> about when the 'load' event should fire. When do you think it should
> fire?

When the image is loaded, when else?  It shouldn't load before the image is 
loaded, as the image isn't loaded, it shouldn't fire an indeterminate length 
of time after the image has loaded, as that's just pointless, it should 
certainly be independant of any other events.

> A better script example would be using addEventListener to register
> for an event that will fire on an element that doesn't yet exist. What
> would you do with this function call?

How can you addEventListener to an element that doesn't exist? 
addEventListener is a method of an element, the element must exist to have 
the method.

> How do you register for an event on an element that
> appears later in the document than your listener?

You don't, why would you possibly want to?  DOM does not support such 
things, and fortunately HTML does support being able to put your script 
after the element, so there is simply no reason to do it.  I know some 
misguided libraries choose to, but I don't think that's a reason to either 
encourage them, or to invent a processing model that bans scripts from 
executing at appropriate times.

Jim.

Received on Wednesday, 2 August 2006 23:07:07 UTC