RE: Script Element Processing (Was: [SVGMobile12] Question on details of when <script> elements execute)

Hi, Ian-

Ian Hickson wrote:
| 
| Hard to be incompatible with existing specs; here's the sum 
| total of the 
| HTML4 spec's take on the matter:
| 
| # If the src attribute is not set, user agents must interpret 
| the contents 
| # of the element as the script. If the src has a URI value, 
| user agents 
| # must ignore the element's contents and retrieve the script 
| via the URI.
| 
| The idea is that the spec (now mostly written, by the way 
| [1]) will be compatible with existing content. 

But if the UAs don't agree (and my and others' tests show they don't), how
can you be "compatible with existing content"?  Existing content relies on
the behavior of the target UA.

SVG Tiny 1.2 has defined script processing to a fine degree (though it is
not yet a Rec).  I'm hoping that other specs, such as yours, will take that
into account.


| > I think it's entirely appropriate for a dedicated spec on 
| something like 
| > script element processing to go into much more detail than 
| a spec like 
| > SVG, which is of course focused on its own subject matter.
| 
| This isn't a dedicated spec on script processing. It's a 
| minor part of a  spec for HTML.

Why only for HTML?  Surely we want to have the same script processing model
across the board?


| _I_ think it is entirely appropriate for a spec to describe 
| how you implement the spec, rather than leaving critical pieces like 
| timing of script execution to the whims of the first mass-market UA 
| implementor, forever to have that reverse engineered by other vendors.
| 
| But I understand that the SVGWG's membership largely 
| disagrees with this position. 

No, we do agree with that.  However, we are getting conflicting feedback on
this issue.  at the same time as people asked for us to fully specify these
details, there is the expectation and pressure not to conflict with existing
UAs (sometimes from the same implementors)... unfortunately, these UAs don't
always agree, so there is no perfect solution.  I'd be surprised if you
hadn't noticed this, and having noticed it, I'm surprised you would gloss
over the challenge that SVG 1.2 faced in specifying it.  If you are
specifying it in your own spec, then I'm sure you're conflicting with one or
more UAs... saying that you are conforming to content is not sensible, since
most of the behaviors at this level would never be relied upon by content
authors.

Previously, no other W3C spec went to such great detail on such matters (as
you mention above), instead leaving it to implementors, so the earlier
drafts of SVG 1.2 did not include an exacting script processing model.  This
was considered normal practice, and I guess it didn't occur to the SVG WG to
do otherwise until prompted by public comments; at that point, we did
specify the script processing model.

We now have a clear step-by-step description of what the behavior must be
that is consistent with respect to elements that exist in the document at
load time, those that are after load time, those that are removed from and
placed back into the DOM, and those which have the IRI to their external
resources changed.  We state exactly when and under what circumstances:
* external resources are loaded
* the effects of changes to the external resource reference have an effect
* script content is placed in the scripting context
* the load event is fired.

We clearly state that the children of script elements are processed
according to the algorithm laid out in textContent.  We state that child
script elements are ignored if there is an external resource provided.

All this is an unprecedented exactitude for script processing in W3C specs,
as was requested by implementors.  We are happy to do so (and I'm especially
happy as an author), but we recognize that we could not match every UA's
model.

Are you saying that we missed something?  If so, please let us know.  If
you'll recall, this was my original question. 


| > Thanks for all your hard work in unifying behavior across 
| UAs.  Such 
| > intensive testing is often a thankless task, but it's very 
| worthwhile.
| 
| Thanks. Why isn't the SVG WG doing the same thing for SVG?

We are.  But we can't control what other Working Groups do.  As I've stated
several times before, I think that this is the sort of backbone stuff that
should have a dedicated spec to remove ambiguities and incompatibilities
between specs.

I'll note that when I asked your advice on this specific matter on IRC, you
flat-out refused to help, making only the overly-broad statement that we
should specify every part of our tech (Anne van Kesteren was much more
helpful), and stating that you would retroactively fix the SVG spec after we
were done.  Similarly, when I've asked you this on www-svg, you have
consistently dodged the question about what needed to be done.

Your agenda is your own business, of course, but I invite you to get beyond
political recriminations and state clearly what parts of our script
processing model you find technically lacking, and suggest a technical
solution.

Regards-
Doug

Received on Monday, 14 August 2006 15:43:57 UTC