- From: <bugzilla@jessica.w3.org>
- Date: Mon, 14 Feb 2011 14:45:42 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11090 --- Comment #3 from Henri Sivonen <hsivonen@iki.fi> 2011-02-14 14:45:41 UTC --- (In reply to comment #2) > Could you elaborate on what the spec should say? I don't know XSLT well enough > to know what terminology is correct here. > > Shouldn't things Just Work due to the definition of the spec in terms of the > DOM/parsing? Maybe. The point is that without explicit Notes, it's all too easy for an implementor to forget XSLT even exists when implementing stuff. The spec should say as notes: * When an XSLT transformation program is triggered by <?xml-stylesheet?> and the browser implements direct-to-DOM transformation, <script> elements created by the XSLT processor should be marked parser-inserted and should be run in the document order (unless defer or async). * XSLTProcessor.transformToDocument adds <script> elements to a document that is not in an active browsing context and, therefore, the <script> elements get they "already started" flag set without ever getting evaluated. The scripts are considered parser-inserted, though, so they .async property returns false in the absence of an async attribute. * XSLTProcessor.transformToFragment creates scripts that aren't parser-inserted and that don't get their "already started" flag set. Thus, the fragment created by XSLTProcessor.transformToFragment is equivalent to a fragment built manually by creating the elements using document.createElementNS. -- 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, 14 February 2011 14:45:44 UTC