- 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