- From: <bugzilla@jessica.w3.org>
- Date: Wed, 29 Dec 2010 08:54:31 +0000
- To: public-html-bugzilla@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