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

[Bug 11090] Add a note about XSLT-created scripts

From: <bugzilla@jessica.w3.org>
Date: Mon, 14 Feb 2011 14:45:42 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PozgM-0007L9-SD@jessica.w3.org>

--- 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

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

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