Bug 17976 - xml-stylesheet with type=text/xsl needs to be handled explicitly
Summary: xml-stylesheet with type=text/xsl needs to be handled explicitly
Status: NEW
Alias: None
Product: WHATWG
Classification: Unclassified
Component: Unwelcome (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Needs Research
Assignee: Michael[tm] Smith
QA Contact: sideshowbarker+unwelcome
URL: http://www.whatwg.org/specs/web-apps/...
Depends on: 14689
  Show dependency treegraph
Reported: 2012-07-18 07:27 UTC by contributor
Modified: 2013-05-30 22:31 UTC (History)
9 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2012-07-18 07:27:08 UTC
This was was cloned from bug 14689 as part of operation convergence.
Originally filed: 2011-11-03 19:02:00 +0000
Original reporter: Henry S. Thompson <ht@inf.ed.ac.uk>

 #0   Henry S. Thompson                               2011-11-03 19:02:01 +0000 
Section 5.5.3 "Page load processing model for XML files" currently mentions xml-stylesheet only in connection with its interaction with the application cache.  The XML Core WG requests that prose be added to cover the case where an xml-stylesheet PI is present, with type other than text/css, and in particular to handle the case where type='text/xsl' or type='application/xslt+xml' by invoking XSLT with the referenced stylesheet and starting the page load process over with the results, consistent with existing browser practice.

The WG also suggests that it might be a good idea to cover the case where no stylesheet PI is present and the root element is not 'html', where existing practice is to produce a default indented tree view of the XML itself.
 #1   Ian 'Hixie' Hickson                             2011-11-03 23:15:13 +0000 
What should the requirements be for the first case?

The second case is already handled by the navigation algorithm as far as I can tell.
 #2   Henry S. Thompson                               2011-11-03 23:22:13 +0000 
(In reply to comment #1)
> What should the requirements be for the first case?

I attempted to give them: invoke XSLT on the current Document with the referenced stylesheet, adopt the result as the current Document.  There are signs you had already anticipated this, for example wrt the timing of <script> in the result, so I'm not sure what you're missing. . .

> The second case is already handled by the navigation algorithm as far as I can
> tell.

Hmm, I tried to track it through the steps of that algorithm and it seemed to fall all the way through -- which clause do you think picks it up?
 #3   Ian 'Hixie' Hickson                             2011-11-11 20:05:19 +0000 
(we spoke about this in person; the second issue will be split into a second bug, and for the first issue we need either some tests demonstrating exactly what is going on, or some proposed text.
 #4   Henry S. Thompson                               2011-11-22 13:51:33 +0000 
Created attachment 1046 [details]
xml-stylesheet PI test cases

A modest set of test cases illustrating existing browser behaviour in response to XML documents with xml-stylesheet processing instructions which reference XSLT stylesheets
 #5   Henry S. Thompson                               2011-11-22 13:57:06 +0000 
Note that the above test cases only cover _single_ xml-stylesheet PIs.  There's
rather a lot of variation in how _multiple_ PIs (of the same type) are handled,
more tests will eventually be forthcoming wrt this issue.  Preliminary
investigation with type='text/css' suggests that Firefox and Opera implement
the spec'd behaviour of offering user choice when the alternate="yes"
pseudo-attribute is present, but Chrome and IE do not (at least, I haven't
found a place where they make the offer, if there is one).
 #6   Henry S. Thompson                               2011-11-23 09:59:27 +0000 
Ah, I found it for IE -- at least IE9 -- I had failed to get the menu bar up, but once I did, the necessary controls are there under View > Style.
 #7   Julian Reschke                                  2011-11-23 10:34:55 +0000 
<http://greenbytes.de/tech/tc/httplink/> has a few test cases relevant to referencing the style sheet using the HTTP Link header fields (as opposed to the stylesheet PI); some of them should be relevant as well, such as support for the correct internet media types, and exposing the stylesheet title through the CSS object model.
 #8   Ian 'Hixie' Hickson                             2012-05-03 16:52:05 +0000 
To resolve this we need a lot more tests, e.g. testing whether the handling of this PI is blocking (by putting a <script> element in the source and having an XSL sheet where the server blocks so it takes a few seconds to download), testing what happens when the XML file or the XSL file (or both) are malformed, testing what happens with various MIME types for the XSL file, testing all the various attributes (e.g. are alternative style sheets honoured? What happens with multiple XSL links?), testing what happens when using <link> elements rather than XML PIs, etc.
 #9   Henri Sivonen                                   2012-05-14 08:32:20 +0000 
FWIW, Firefox's behavior in this scenario is considered a bug.
Comment 1 Ian 'Hixie' Hickson 2012-08-26 03:21:08 UTC
Shouldn't this be defined for SVG-only browsers too? Or XML+CSS-only user agents? (i.e. why is it something that should go in the HTML spec?)

Anyway, in the absence of the tests mentioned above, this is in limbo.
Comment 2 Ian 'Hixie' Hickson 2012-10-31 22:42:47 UTC
From bug 14689 comment 32:
> >
> > testing what happens when the XML file or the XSL file (or both)
> > are malformed
> I can easily transform any or all of the tests already attached here to be
> ill-formed in those ways, but I have no idea what kind of result report you
> would need

I need to know things like (in no particular order):

- Does the XSL file get applied at all if it is a slow-loaded XSL file that is ill-formed at the end?
- Does an XSL file that is ill-formed at the start delay the load event for the entire time that the file is loading? (Or is the load canceled early maybe?)
- What is the processing model for an XSL file in general? Does it prevent <script> execution in the parser after the <link> or <?xml-stylesheet> PI?
- What events fire? 'load'? 'DOMContentLoaded'?
- What is the .URL of the post-transformation Document?
- What DOM gets transformed if a script is mutating the Document that references the XSL sheet?
- What happens if XSL sheet <link> references are added dynamically?
- What happens if a <link> is enabled or disabled dynamically?
- What if they're removed dynamically?
- Everything in note #8 above.
- Everything in comment 1 above. In particular, why is this HTML-specific?

Basically, what is the processing model. When does the transformation happen? What happens before and after? What should the spec say. I know nothing of XSL, so I'm not in a good position to answer these questions.

> > testing what happens with various MIME types for the XSL file
> Can you point me to a parallel set of tests for xml-stylesheet
> type='text/css' so I can see how you expect this to be done?

An old set of CSS import tests I wrote years ago is here:


(Note that many of these tests aren't valid anymore, but they should give you some ideas.) This is a very simple set of tests, though, and not representative of what we need. In particular, they do very little (if any) scripted DOM testing, which is a prerequisite now.

The tests at http://www.w3.org/XML/2011/11/ssTests/ aren't very useful; they aren't really tests, more demos, and they only seem to look at the most basic of things (e.g. no scripting that I could see, nothing that would really show what the processing model was).
Comment 3 Ian 'Hixie' Hickson 2013-05-30 22:31:47 UTC
See bug 18460.