W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > January 2011

[Bug 11295] Make script-inserted external scripts that have .async=false execute in the insertion order, default to true

From: <bugzilla@jessica.w3.org>
Date: Mon, 03 Jan 2011 13:20:29 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PZkKr-0007M1-CT@jessica.w3.org>

--- Comment #11 from Henri Sivonen <hsivonen@iki.fi> 2011-01-03 13:20:26 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> > When a script element node is created, if it is being flagged as
> > parser-inserted, set its force-async flag to false. Otherwise, set its
> > force-async flag to true. (Note that createContextualFragment, innerHTML and
> > XSLTProcessor::transformToFragment-created scripts are not flagged as
> > parser-inserted.) This flag setting happens before any attributes (even
> > parser-set ones) are set on the node (so a fragment parser-set async attribute
> > may modify the flag shortly after).
> That doesn't really make sense. The elements created by the parser are created
> with their attributes already set. But I guess we can get the same effect in a
> different way.

If you want to make the spec treat element creation and attribute setting as an
atomic operation when performed by the parser, you can rewrite the above as the
force-async flag getting initialized to false when the parser creates a
parser-inserted node that has the async attribute.

> Overall this proposal seems to add a lot of complexity without a really good
> argument. Are there really that many sites that depend on this?

There are individual sites (Wikia, Hotmail, beta.edmunds.com) and libraries
(LABjs, 'order' plug-in for RequireJS and OpenLayers) that exploit the way
Firefox < 4 deviates from WebKit/IE/spec to get improved performance over
WebKit/IE/spec. The rationale for this feature in Firefox 4 is to give these
sites/libraries a way not to regress performance relative to Firefox 3.6 while
making it possible for Firefox 4 to default to the WebKit/IE/spec behavior (if
you don't touch the async DOM property). Fortunately, the sites and libraries
that have been relying on the old spec-incompliant and WebKit/IE-inconsistent
behavior of Firefox have been few enough and extraordinarily responsive to
evangelism to make it possible to proceed what is described in comment 0.

Putting what's suggested in comment 0 into the spec and having other browsers
implement it would allow other browsers to benefit from the performance
optimizations now available to Firefox.

Currently, in cases other than LABjs and RequireJS, WebKit away by not breaking
due to UA sniffing.

> What are other UAs intending to do here?

As far as I can tell, WebKit seems to be pretty far along implementing this if
only you made the spec change first:

If WebKit waits for you and you wait for WebKit, there's a deadlock. AFAICT,
WebKit waiting for what you do meets your standard of "whatever browsers would

Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 3 January 2011 13:20:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:03 UTC