This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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. ================================================================================
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.
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: http://www.hixie.ch/tests/evil/css/import/ (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).
See bug 18460.