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

Hi Jim,

> So a screen user reader would expect a 1mb document to be fully downloaded
> before it even started to read the first line? I am astonished to believe
> that, surely they, like anyone else want to get to the content as soon as
> possible, why would they want to wait, simply to be told "XHTML Applciations
> and XML processors" etc.

My argument was not that the entire 1Mb document must be fully
downloaded and parsed before it can be processed; my point was that
the behaviour of two processors, one that *does* wait until the
document is fully parsed, and one that makes use of the document 'in
some way' before it is fully parsed, should be to all intents and
purposes the same.

My thinking on why they need to be the same, is based on looking at
XML processing, and the way that the XML specification leaves open the
possibility of SAX and DOM-style processing (any style, actually).
This means that for XHTML to be an XML language, we cannot enforce one
type of processing or another, and so the only thing we can say is
that whatever processing model is used, the behaviour of the document
will be the same.

Now, I'm happy to admit that this has not been done so far, but to
achieve interoperability, I would argue that it does need to be done.
The kinds of things I'm thinking of would be to (for example) define
<img> in such a way that these factors are taken into account. So we
might say something like:

  It is ok to retrieve the document pointed to by the @src attribute at any time
  in the load sequence, and it is even acceptable to render the image in a
  system that is progressively rendering, but the browser needs to be aware
  that when dispatching the 'load' event to indicate that the <img> element
  has completely loaded, not all listeners may have been registered, and
  therefore the event needs to be queued until the document has been fully
  parsed.

For <script> we might say:

  The contents of a script element are not executed until receipt of the 'load'
  event.

Or if we want to allow things like using XHR before a document has
fully loaded, we might say:

  The contents of a script element are not executed until receipt of the
  closing script tag, but modifications to the XHTML document are not
  allowed prior to the 'load' event firing.

My point is not to define it now, but to suggest that by taking this
kind of approach, we can define functionality in such a way that
regardless of how an author writes their document, and regardless of
how any particular browser works, we will get the same *behaviour*.

It's obviously the case that browsers will optimise to achieve good
performance, and it would certainly be a good idea to use SAX. But if
we develop a processing model that *relies* on SAX, rather than
*allowing* SAX, then in my view we have strayed from XML's open
architecture.

I would therefore suggest that by carefully thinking through these
kinds of issues within the context of a goal of interoperability, we
will actually make things a lot, lot easier for authors. The
alternative, of just letting people _hope_ that their code works in
all the different browsers, seems far too much like yesterday's model
of web applications, and is what I think a lot of people are working
towards avoiding.

Regards,

Mark

-- 
Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/
b: http://internet-apps.blogspot.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Wednesday, 2 August 2006 20:51:16 UTC