W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > December 2010

[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: Wed, 29 Dec 2010 08:54:31 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PXrnj-0007JB-S4@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11295

Ian 'Hixie' Hickson <ian@hixie.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |annevk@opera.com,
                   |                            |ap@webkit.org,
                   |                            |eseidel@apple.com,
                   |                            |ian@hixie.ch,
                   |                            |mjs@apple.com,
                   |                            |simonp@opera.com,
                   |                            |w3c@adambarth.com

--- Comment #1 from Ian 'Hixie' Hickson <ian@hixie.ch> 2010-12-29 08:54:31 UTC ---
(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.


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? What are other
UAs intending to do here?

-- 
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 Wednesday, 29 December 2010 08:54:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:36 UTC