Re: xhtml 2.0 noscript

Hi Bjoern,

Haven't heard from you in a while, but good to see you haven't been
wasting time in charm school.

Putting aside whether truth has different degrees, ranging from the
trivial to the incredibly complicated, and passing over whether I am
indeed talking nonsense (and if so, what the point of you replying to
me in such detail would be, since you will surely only encourage my
inane meanderings), I'll move on to the *only* question which can
resolve this issue, and that is: when exactly do you think an inline
occurrence of document.write() would be executed in an XHTML document?

I'll explain how I see it (or to be trivially precise, I'll talk some
more nonsense):

As we know, XHTML is an XML language, so the document will be loaded
in an XML processor. We therefore have two choices here, as to the
'architecture' that we can adopt. The first is that we fully load the
document in our XML processor, and then pass the loaded document to
our XHTML processor. The second is that we actually process the script
at the same time as loading the document in the XML processor.

The problem with the second approach is that this then ceases to be a
standard use of an XML processor, since it now 'knows' about XHTML (or
at least it knows about the script element and the document.write()
function).

There is no 'space' in the XML specification to support this kind of
knowledge inside the XML parser. In fact, the terminology is quite
precise, talking of an "XML processor" providing information to an
"application", in a predictable and consistent way. (I.e., you can use
any XML processor to feed data to your XHTML application and things
should always work in the same way.) This therefore points towards
using option 1 of our two choices.

Of course you could argue for a third alternative, which is a kind of
pipelined approach; we could use SAX to feed the XML document from the
XML processor to the XHTML processor, and the XHTML processor could
work on scripts elements as it finds them.

The problem with this approach is that once again the XML spec doesn't
allow for this processing model. The specification for XML only deals
with the idea of a conceptually complete XML document being passed
through to some application, and we should stick with that. That's not
to say that implementers couldn't support further optimisations that
use SAX in order to provide features like incremental rendering, for
example, but the point is that the *logical* model remains that of
having the DOM completely processed before anything happens to it.

(So the point is not to say that SAX-style processing can't be used,
since that's an implementation detail. The point is to say that the
'model' or 'architecture' must follow the usual XML one, and so must
'act as if' the XML processor was passing a completed document to the
XHTML application.

If we didn't take this approach, we would have two different ways that
an XHTML processor could behave, with the difference being determined
by how implementers had decided the XML should be fed from the XML
processor to the XHTML application, and this is certainly bad
practice.)

Given this 'architecture' or 'processing model', it means that any
executions of inline document.write() calls will take place after the
entire document has been loaded, and so will not be modifying the
*initial* document. This means that the same document will *always* be
loaded into *any* XHTML viewer, and it is only once loaded that script
elements could be processed and make a difference. There is therefore
no need to support <noscript>, since during the initial loading
process there are no 'alternative routes'.

Regards,

Mark


On 29/07/06, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Mark Birbeck wrote:
> >document.write() is normally carried out as the document is loading,
> >by interspercing <script> elements within the normal mark-up. This
> >means that the *initial* document at the point of completion of the
> >'onload' event could be different when running in a browser with
> >script, and one without.
>
> Two originally identical things may be different after you change one of
> them. Yes, that's trivially true, regardless of what triggers the change
> (you can just use removeChild instead of document.write if you like). So
> if this is supposed to explain
>
> >But with XML we really need to have the document fully loaded and
> >parsed before we can start manipulating it, which means that
> >document.write() doesn't mean anything.
>
> then you really argue that <script> execution should be delayed until
> after the document has been fully transformed into a tree. As you do
> not seem to argue that, your argument doesn't make sense. Further, you
> just claim "we really need" this. We do not. And we do not have that
> in many cases either. What you say is nothing but nonsense.
>
> >So if XHTML doesn't have document.write(), then that means that
> >whatever mark-up you put into the body of your document you can
> >guarantee it will be the same after the 'onload' event regardless of
> >whether the browser has script turned on or off, or doesn't even
> >support script.
>
> That is obviously incorrect, already for the fact that scripts other
> than those inside <script> will have control passed to them before any
> 'load' event occurs, a trivial example being
>
>   <img onerror='...removeChild(this)' ... />
>
> document.write is also not a property of XHTML, but of the HTML 4.01
> and XHTML 1.0 Document Object Model, and yes, it does have the write
> method for XHTML.
> --
> Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
> Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
> 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
>
>


-- 
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 Saturday, 29 July 2006 15:34:26 UTC