RE: url params et al

 
Mark,

The way we do it is via DOMContentLoaded on Mozilla browsers and for IE and
Opera there is the document readystate set to interactive.

These states are fired after the DOM has been built and before images and
objects etc catch up.

Francisco
-----Original Message-----
From: www-forms-request@w3.org [mailto:www-forms-request@w3.org] On Behalf
Of Mark Birbeck
Sent: 29 August 2006 11:07
To: Erik Bruchez
Cc: www-forms@w3.org
Subject: Re: url params et al


Erik,

> It would be a huge drag to prevent img/@src to work, because img/@src 
> is a big use case for AVTs IMO, and users will not understand easily 
> why a/@href would work but img/@src not!

My point was not that we shouldn't have this functionality, but that we need
to work out how we will get it.

My proposal was just an opener. I'm saying that if we take as a
starting-point that AVTs cannot be used prior to the DOM load event then at
least we have a clear dividing line for which attributes are in and which
are out. The reason I believe this to be important, is that differentiating
attributes on the basis of their *type* is not good enough--some XPath
expressions work fine as AVTs, and some simple text values don't work at
all. You might as well pick all attributes that begin with a vowel.

Now, once you've drawn some line in the processing (it doesn't matter where,
really, it's just to get things rolling) then of course we can agree that
allowing AVTs in img/@src is desirable. (Although I disagree that authors
don't understand the difference between traversing a link on request and one
on load.)

But with the clear line having been drawn, the question becomes not "it
would be terrible if we couldn't use AVTs in img" (that's a given), but "how
do we move this dividing-line backwards in time so that images can be loaded
from URLs that are soft"? I'm not saying it can't be done, but I am saying
it's work that needs to be done.

The reason it's tricky to move it before "DOM load" though, is that there is
no connection between the XForms events that concern the model, instances,
and so on (such as xforms-ready) and the HTML loading sequence (which loads
scripts, images, objects and so on).
This means that were we to choose "xforms-ready" (for example) then we have
nothing that says all images haven't already been loaded by the time
"xforms-ready" is complete.

Unfortunately, as much as we want this functionality, we can't just simply
assert it. So to go back to what I thought was the agreed goal--to find some
common ground for implementation, *not* to write spec-ready text--I would
still suggest that a first wave of implementation work could be to implement
as AVTs any attribute that is used after the document has been loaded. And
then from there, see whether we can use our experience to help us provide
the same support for further attributes.

And it may actually be the case that img/@src cannot support AVTs as things
stand. I wouldn't lose any sleep over that, or waste too much time with it,
since we have xf:output with @mediatype, and for that the loading sequence
and relationship to instance data is clearly defined. (And we're using
xf:output with @mediatype values of video and audio too, so we have a
clearly defined way to support h:object
aswell.)

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/