This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 11090 - Add a note about XSLT-created scripts
Summary: Add a note about XSLT-created scripts
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: All All
: P1 critical
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-10-19 09:42 UTC by Henri Sivonen
Modified: 2011-08-04 05:16 UTC (History)
5 users (show)

See Also:


Attachments

Description Henri Sivonen 2010-10-19 09:42:00 UTC
Please add text (note or normative; I don't care as long as it's there) about XSLT-created scripts. There are three cases:
 1) <?xml-stylesheet?>-triggered transform.
 2) Using XSLTProcessor.transformToDocument
 3) Using XSLTProcessor.transformToFragment

In case #1, scripts created by the XSLT processor that transforms directly into DOM nodes should behave like parser-inserted scripts in the sense that they execute in insertion order. That is, inline and external scripts maintain order relative to each other. (In principle, one would expect the XSLT processor to be blocked upon a parser-blocking script, but in practice, the only known implementation didn't actually block the XSLT processor--just executed the scripts in order. Even if the spec said to block the XSLT processor, I doubt we'd prioritize changing this.)

In case #1, if the XSLT processor transforms to a stream and the stream is reparsed, the right thing happens.

I didn't yet test what the legacy behavior for cases 2 and 3 is.

(I so wish the spec had had a reminder about this a couple of months ago...)
Comment 1 Henri Sivonen 2010-10-19 12:12:24 UTC
For case #2, let's say the scripts shouldn't run, since Firefox and WebKit don't run and only Opera runs.
http://hsivonen.iki.fi/test/moz/scripts/XSLTProcessor-transformToDocument.html

For case #3, the scripts probably should run like script-inserted scripts, since they run in Firefox and Opera (though not in WebKit):
http://hsivonen.iki.fi/test/moz/scripts/XSLTProcessor-transformToFragment.html
Comment 2 Ian 'Hixie' Hickson 2011-02-08 20:58:38 UTC
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? I don't understand why anything is underdefined here.
Comment 3 Henri Sivonen 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.
Comment 4 Ian 'Hixie' Hickson 2011-05-03 01:09:34 UTC
The requirements you propose do not result in the behaviour you describe.

The interaction of XSLT processors with the event loop and with document load is not defined. We'd have to define both of those, and then have all the machinery we have for XML parsers, to get XSLT processors defined well enough that this would all work as you describe. I don't propose to do that in the HTML spec (to start with, I don't understand XSLT well enough).

Instead, I've added some hand-wavy non-normative text based on your bullet points in comment 3. I hope it's enough. Let me know if you want more.


EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Partially Accepted
Change Description: see diff given below
Rationale: see above
Comment 5 contributor 2011-05-03 01:10:34 UTC
Checked in as WHATWG revision r6049.
Check-in comment: Try to warn implementors about XSLT.
http://html5.org/tools/web-apps-tracker?from=6048&to=6049
Comment 6 Michael[tm] Smith 2011-08-04 05:16:55 UTC
mass-move component to LC1