W3C home > Mailing lists > Public > www-html@w3.org > August 2006

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

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Wed, 2 Aug 2006 22:35:54 +0100
Message-ID: <640dd5060608021435i674ae346s3678ef39720f7995@mail.gmail.com>
To: www-html@w3.org


What has 'idealism' got to do with it?

I don't want to be rude, but in _any_ circumstance it would be weak to
simply dismiss an argument you don't agree with as "idealistic" (or
"pointless"), and I wouldn't even do that in the pub. But amongst a
group of people involved in producing standards, it's both a weak
tactic and a superfluous tautology. Standards are by their nature
idealistic, and not just in the utopian sense--you could argue that
trying to move reality towards an 'idea' makes them idealistic in a
Hegelian sense, too.

So, let's accept that we are all engaged in idealism, whether we like
it or not...or are prepared to admit it to ourselves or not. :) I've
asked a couple of concrete questions below, and I'd be interested to
hear how proponents of the view that we shouldn't define a processing
model think they should be handled. (So you or anyone else, Jim.)

> I can appreciate that, but that means you cannot change a document in
> response to an event - even something as trivial as updating a value of a
> text input in response to another, couldn't work as the infoset is different
> before and after load.

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. 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, something I blogged about yesterday in relation
to a discussion on the XForms list:


> > For <script> we might say:
> >
> >  The contents of a script element are not executed until receipt of the
> > 'load'
> >  event.
> 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? Of course
that would be a retrograde step, but no-one is arguing for it. I'm not
seeing why you think that standardising on the processing model for
XHTML documents would introduce this requirement.

> >we will get the same *behaviour*.
> I appreciate your aim, I just don't think it is useful, if you're going to
> have the broken user experience suggested in this thread, I particularly
> don't think it's useful simply to give some idealistic idea of
> interopability of document.documentElement.lastChild.appendChild( ) which is
> something that people don't need to use.

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

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?

> We have interopability today on the web in this area, and we don't rely on a
> processing model as you describe, the goal of having an XML document in some
> way unchanging during load seems an entirely pointless one that can only
> harm the web.

We don't have interoperability, today. As I said before, that's why so
many Ajax libraries are having to introduce wrappers to deal with this
kind of stuff. How do you register for an event on an element that
appears later in the document than your listener?



Mark Birbeck
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
Received on Wednesday, 2 August 2006 21:36:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:13 UTC