This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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.
(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?
(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.
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
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).
(In reply to comment #5) > . . . 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). 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.
<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.
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.
(In reply to comment #8) > 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), FWIW, Firefox's behavior in this scenario is considered a bug.
This bug was cloned to create bug 17976 as part of operation convergence.
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: Rejected Rationale: Hi Henry, this would indeed be worth defining, especially since there is a lot of variation in some of the possible cases. That being said, the amount of research required to properly specify it does not fit into this release's timeline. We'll be looking at this for .next. Thanks!
I'm taken completely aback by this decision. All shipping browsers already implement this! Surely it's appropriate to document the mainstream behaviour, as illustrated by the test cases I supplied nearly a year ago.
(In reply to comment #12) > I'm taken completely aback by this decision. All shipping browsers already > implement this! Surely it's appropriate to document the mainstream behaviour, > as illustrated by the test cases I supplied nearly a year ago. Yes it is appropriate — no one said otherwise! RESOLVED LATER means we'll resolve it later, not never. It may even be soon; it just won't be in this release is all I'm saying.
Sorry, what does "this release" mean, if not HTML 5? The idea that HTML5 should not include support for a core behaviour of XML on the web, which has been supported by all shipping browsers for many years, seems bonkers. I'm speaking for myself, but I expect the XML Core WG will shortly say exactly the same thing, officially and strenuously.
Why is this considered to be in scope for the HTML spec at all? Shouldn't the XSLT spec define XSLT processing?
It's not part of an HTML spec, but it *is* part of a *browser* spec, and this is what the HTML spec is actually. The XSLT spec defines the transformation, the stylesheet PI spec defines the format of the PI. Optimally, the browser spec doesn't need to do much more than referencing the PI spec.
(In reply to comment #14) > Sorry, what does "this release" mean, if not HTML 5? The idea that HTML5 > should not include support for a core behaviour of XML on the web, which has > been supported by all shipping browsers for many years, seems bonkers. I'm > speaking for myself, but I expect the XML Core WG will shortly say exactly the > same thing, officially and strenuously. It means 5.0 — after that there's 5.1. We're pursing an aggressive timeline to get 5.0 out and there simply is no way that I can see of the work required here to fit into that frame. We're going to be developing the current version and the next version in parallel, and HTML.next is not expected to come 15 years later but rather in relatively quick succession, with incremental changes being folded in as they are ready. So the idea is not that we're excluding this but rather that we're not solving it this month. I can only hope that the XML WG will understand that as consensus creeps in this petty pace from day to day we can't address all problems at once, and do have to prioritise so that we release something before our brief candles are out.
My worry is that if HTML5 goes to CR without support for xml+xml-stylesheet[XSLT], browser vendors/suppliers may _remove_ XSLT from their browsers, and then we'll never get it back. I'm also perplexed by the assertion that there's a lot of editorial work involved here: the work for xml-stylesheet[CSS] will surely be done -- adding basic support for an additional stylesheet language isn't a big deal. Both I (above) and Julian have provided test materials.
(In reply to comment #18) > My worry is that if HTML5 goes to CR without support for > xml+xml-stylesheet[XSLT], browser vendors/suppliers may _remove_ XSLT from > their browsers, and then we'll never get it back. No need to worry about that, browsers won't remove anything just because it's not in the HTML5 CR. > I'm also perplexed by the assertion that there's a lot of editorial work > involved here: the work for xml-stylesheet[CSS] will surely be done -- This is already specified in http://dev.w3.org/csswg/cssom/#requirements-on-user-agents-implementing-the-xml-stylesheet-processing-instruction
Instead of resolving as later, shouldn't this be reassigned to the HTML.next component?
(In reply to comment #17) > It means 5.0 — after that there's 5.1. We're pursing an aggressive timeline to > get 5.0 out and there simply is no way that I can see of the work required here > to fit into that frame. Would providing complete text of needed editoral changes in a form of Git pull request change this? Jirka
In agreeing to accept https://www.w3.org/Bugs/Public/show_bug.cgi?id=15180 (XML _without_ xml-stylesheet), you say "Rationale: It's already implemented, might as well be described correctly." That's precisely the case here as well! And the necessary scaffolding is already in place. . .
(In reply to comment #18) > My worry is that if HTML5 goes to CR without support for > xml+xml-stylesheet[XSLT], browser vendors/suppliers may _remove_ XSLT from > their browsers, and then we'll never get it back. I wouldn't worry about that — either there's content relying on that and it won't get removed, or there isn't content relying on XSLT anywhere on the big wide Web and what's in the spec won't change that. So that should definitely not be a concern. > I'm also perplexed by the assertion that there's a lot of editorial work > involved here: the work for xml-stylesheet[CSS] will surely be done -- adding > basic support for an additional stylesheet language isn't a big deal. Both I > (above) and Julian have provided test materials. Well if it's not much work, rest assured that we accept patches :) Can you answer all the questions in comment #8 and those that stem from there? (In reply to comment #22) > "Rationale: It's already implemented, might as well be described correctly." > > That's precisely the case here as well! And the necessary scaffolding is > already in place. . . You'll note that the other bug which you're quoting was reopened (with good reason).
(In reply to comment #20) > Instead of resolving as later, shouldn't this be reassigned to the HTML.next > component? My understanding was that it was exactly the same thing — but I've just arrived so I could be wrong :)
(In reply to comment #21) > (In reply to comment #17) > > It means 5.0 — after that there's 5.1. We're pursing an aggressive timeline to > > get 5.0 out and there simply is no way that I can see of the work required here > > to fit into that frame. > > Would providing complete text of needed editoral changes in a form of Git pull > request change this? It always helps, but it would need to be reviewed and given the time constraints might still only be accepted in v.next. While we'd be grateful, I would be sorry if you were to put a lot of work into this and it got deferred anyway.
Now using the HTML.next component instead of RESOLVED LATER. Purely administrative change, sorry for the noise.
As I have said before, I need Gillian Gordon Crozier removed as adim. Also, a compleat separation from her work group. In my opinion, she should be subject to a general investigation Andrew H Goldberg
The XML Core Working Group objects to the decision to mark discussion of the XML stylesheet PI with type='text/xsl' as either "RESOLVED LATER" or "HTML.next". The stylesheet PI is widely supported and has been in use for a long time. It is an important part of the browser API. Some test cases[1] for the XML stylesheet PI with type='text/xsl' have been attached to the bug report[2]. In a sampling of the University of Amsterdam XML Web Collection, around 10% of the documents[3] have an XML stylesheet PI with type='text/xsl'. The XML Core WG remains concerned that the absence of a mention of support for the XML stylesheet PI with type='text/xsl' would serve to discourage users from taking advantage of the existing functionality and might set implementers on a path towards deprecating the feature. The XML Core WG feels strongly that some mention of support for the XML stylesheet PI with type='text/xsl' or type='application/xslt+xml' needs to be included in the initial HTML5 Recommendation. [1] http://www.w3.org/XML/2011/11/ssTests/ [2] https://www.w3.org/Bugs/Public/attachment.cgi?id=1046 [3] http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Sep/0041.html
(In reply to comment #28) > The stylesheet PI is widely supported and has been in use for a long time. > It is an important part of the browser API. Some test cases[1] for the XML > stylesheet PI with type='text/xsl' have been attached to the bug report[2]. > (...) > The XML Core WG feels strongly that some mention of support for the XML > stylesheet PI with type='text/xsl' or type='application/xslt+xml' needs to > be included in the initial HTML5 Recommendation. Norm, no one is contesting that there are people using xml-stylesheet with XSLT or that it is important to users who rely on it. The heart of the matter is that it is simply not feasible to define how it works at the requisite level of concision within the very small time frame we have before entering CR. We are fixing bugs, not taking new features. Please note that as soon as 5.0 hits CR, we will be issuing a FPWD or 5.1 — I must therefore emphasise that it is not as if all specification work was about to stop until 2015. I would be happy to work with the XML Core WG to properly specify this feature as part of 5.1. In the meantime, you seem to indicate that you might be satisfied with "some mention of support". Can you clarify what that would involve? Do you have some suggested text? Would a non-normative paragraph work for you? If not then I'm afraid that the next step will have to be escalation.
(In reply to comment #29) > > The heart of the matter is > that it is simply not feasible to define how it works at the requisite level > of concision within the very small time frame we have before entering CR. Norm: feel free to prove Robin wrong by making a concrete proposal. :-) I'll also note that it is possible for this to be documented in a separate spec. See Plan 2014: http://dev.w3.org/html5/decision-policy/html5-2014-plan.html And in particular: http://dev.w3.org/html5/decision-policy/html5-2014-plan.html#extension-specs http://dev.w3.org/html5/decision-policy/decision-policy-v3.html#cr-integration
Henry, Norm: I'm happy to write the text that should go in the spec (and am indeed planning to do so — bug 17976 isn't closed), but what I need before that can happen is the tests described in comment 8. Without those tests, I have no way to know what to spec. I don't have the necessary knowledge to write the tests. Once I've written the text, it's easy for Robin and co to take my text and put it in the W3C version, in case that's what you care about (as opposed to just the WHATWG version). Telling us to do work for you without being willing to at least contribute tests isn't going to work since you care about this more than we do.
(In reply to comment #31) > Henry, Norm: I'm happy to write the text that should go in the spec (and am > indeed planning to do so — bug 17976 isn't closed) Great, thanks > but what I need before that can happen is the tests described in comment 8. It's not laziness or disinclination that has lead to the lack of reply to comment 8, but rather confusion. Quoting from comment 8: > 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 > 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? > 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), Not sure I have the necessary expertise to do this -- maybe Norm Walsh can help here? I recall recently running across a bunch of xsl-stylesheet tests you had written, can't remember where, which might have begun to cover this??? > 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. Not sure this gives you enough to work with, but I've attached a further set of tests in this space. Note also Julian Reshke's offer at comment 7.
Created attachment 1225 [details] multiple stylesheet PI tests All the tests in this and the earlier attachment are visible on the web at http://www.w3.org/XML/2011/11/ssTests/
Please see my comments in bug 17976.
The XML Core WG considered this issue again at our face-to-face[1]. We recognize that it's too late to attempt to get normative changes into this version of the spec. We're still committed to helping move something forward normatively in this or another spec in the future. In the meantime, we suggest a note along the following lines (editor, salt to taste) in section 5.6.3: Note: Many existing user agents support the 'text/xsl' (or 'application/xslt+xml') style sheet type, with XSLT [ref] as the relevant supported styling language. When the browsing context has a StyleSheet of that style sheet type, such agents transform the current XML document using the XSLT stylesheet retrieved from the style sheet location (typically supplied via an xml-stylesheet processing instruction) and rendering (or otherwise processing) the document that results from that transformation. The precise details of this process will be defined in a future specification. [1] http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Oct/0059.html
+1, but: (In reply to comment #35) > The XML Core WG considered this issue again at our face-to-face[1]. We > recognize that it's too late to attempt to get normative changes into this > version of the spec. We're still committed to helping move something forward > normatively in this or another spec in the future. > > In the meantime, we suggest a note along the following lines (editor, salt > to taste) in section 5.6.3: > > Note: Many existing user agents support the 'text/xsl' (or > 'application/xslt+xml') style sheet type, with XSLT [ref] as the IE and Firefox support application/xslt+xml. Change requests to Apple, Chrome, and Opera have been ignored so far. See http://greenbytes.de/tech/tc/xslt/#pi-ax-ax > relevant supported styling language. When the browsing context has a > StyleSheet of that style sheet type, such agents transform the > current XML document using the XSLT stylesheet retrieved from the > style sheet location (typically supplied via an xml-stylesheet > processing instruction) and rendering (or otherwise processing) the > document that results from that transformation. The precise details > of this process will be defined in a future specification. > > [1] http://lists.w3.org/Archives/Public/public-xml-core-wg/2012Oct/0059.html
(In reply to comment #35) > In the meantime, we suggest a note along the following lines (editor, salt > to taste) in section 5.6.3: This has been committed: https://github.com/w3c/html/commit/dab090a81e0269b1ad63922ebb5f897ade3488e0 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: Added a note explaining that XSLT processing is possible, though not defined. Rationale: Clarifies real-world situation; a proper in-depth definition of the actual processing is nevertheless still required.
Thanks -- Marked this as LATER to remind us that it needs more work in a subsequent edition/version
HTML5.1 Bugzilla Bug Triage: Moved to GitHub issue: https://github.com/w3c/html/issues/214 If this resolution is not satisfactory, please copy the relevant bug details/proposal into a new issue at the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new where it will be re-triaged. Thanks!