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

"Mark Birbeck" <mark.birbeck@x-port.net> wrote in message 
news:640dd5060607291100m43f37dc4s2a1232eb769190f3@mail.gmail.com...
>> Let's widen the situation away from XHTML - to include XML Events, XML
>> Events are a generic process, this means that an XML processor that 
>> wanted
>> to use it would need to support them, these break the idea that what 
>> arrives
>> onload is the same as arrives before unload, there's no seperation from
>> XHTML/XML here.
>
> But I don't think you'd say that the XML Events processing is part of
> the 'XML processor', in the sense that the term is used in the XML
> spec. At least at a logical level, it would be a different layer, even
> if some processor that you installed and ran supported this.

Nope I wouldn't, but I'd be pretty concerned that XML Events was 
incompatible with XML - I don't believe it is, but I can't see any 
difference between it and the arguments being used for document.write (there 
are other arguments for document.write, but non-mutation pre-load isn't one 
of them)

> * the XML processor passes a complete DOM to the XHTML processor;
> * the XHTML processor starts using this DOM:
>   * attaching event handlers from XML Events;
>   * running any inline scripts;
>   * loading any images and other resources;
>   * and so on;
> * the 'onload' event is then dispatched, right at the end.

This means that any use of document.documentElement.lastChild etc. in the 
scripts will always be the last child in the document - if scripts are 
executed when they're found then the lastChild would be different, this 
means it's easy for us to test what implementations have chosen to do - and 
in all the ones I can find, the lastChild is where the script is executing, 
and not at the end of the document.

>> This interpretation though knocks out an awful lot more than just
>> document.write - it also knocks out the majority of user agents - 
>> including
>> all the XHTML ones I had to hand - you've got my test case.
>
> What do you mean by an XHTML user agent, though? There are those that
> 'understand' XHTML 1, that's true, but are you talking about ones that
> actually process the XML as XML? Which ones would you include?

Opera 9 and a almost trunk Mozilla I had to hand both in "XML-mode".

> I don't see anything wrong with what you did in your earlier post; all
> I'm doing is saying that I don't think there is any scenario where you
> can say that your script is executed *before* the document is fully
> parsed that makes for interoperable behaviour.

I see what I did in the previous as identical to document.write - the 
document mutates whilst being parsed (either by using lastChild of something 
that is not otherwise finished loading, or through document.write)

> Let's put it the other way round; if I were to implement an XHTML
> viewer by first loading the XML into a DOM and validating it, before
> passing it through to a renderer, what is wrong with that?

Nothing, it just wouldn't interopeate with other existing implementations - 
it's no more or less to spec at least over everything I can find here.  The 
main problem is that the event specifications do not allow such delaying.


>The problem
> is that if we allow a processor to *choose* to run some of the script
> before the document is completely available (conceptually), then we
> rule out this 'naive' approach.

It's unfortunate that the spec didn't say this (XHTML 2 could of course) but 
that doesn't change XHTML 1 where it specifically didn't limit this and 
existing implementations are not following that route.

> Far better then to say that the approach is that the complete document
> should be 'available' before the DOM can be modified.

This is incompatible with a conforming high performance SVG 1.1 user agent 
(or whatever they called it) which requires progressive rendering, which 
requires that events can be fired before the document is fully parsed (e.g. 
mouse move events..)

> I'm not at all saying that everything I describe here is already
> defined in XHTML 2, XHTML 1, XML Events, etc.--so it's not a question
> of (mis)interpretation. Instead I'm *proposing* that this is how it
> could be done, in order to allow for consistency and interoperability.

I understand that, but I think it would be a great shame, as it's 
incompatible with other specifications (e.g. SVG) it's incompatible with 
implementations (e.g. Opera 9) and it makes the web a lot less interesting 
place (e.g. no progressive rendering - as you can't have progressive events, 
so a UI would be inconsistent)

Cheers,

Jim.

Received on Saturday, 29 July 2006 18:46:05 UTC