This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Split off from https://www.w3.org/Bugs/Public/show_bug.cgi?id=14689 per Comment 3. When an XML document is processed, but _no_ stylesheet PI is present and the root element is not 'html', existing practice is to produce a default indented tree view of the XML itself. It probably doesn't make sense to _require_ this, but it would be good if somewhere in section "Page load processing model for XML files" the 'other XML, no stylesheet' case was explicitly called out, and such default behaviour allowed.
This obviously should *allow* UAs to process a stylesheet link header field.
Thanks Julian -- yes, I should have said, since CSSOM already covers the Link header case (along with basic xml-stylesheet stuff) "When an XML document is processed, but no stylesheets are associated with it per "6.3 Style Sheet Association" in CSSOM (http://dev.w3.org/csswg/cssom/#style-sheet-association) and the root element is not 'html', . . ."
Checked in as WHATWG revision r6928. Check-in comment: copypasta http://html5.org/tools/web-apps-tracker?from=6927&to=6928
Apologies, that was intended for bug 15177.
This bug was cloned to create bug 17980 as part of operation convergence.
Actually, the rules for processing this appear to be more complex than just the lack of association with a style sheet. For instance, if you serve (as XML) the following XML document: <foo><p>foo</p></foo> You will consistently get the tree source rendering. If however you modify it to be: <foo><p xmlns='http://www.w3.org/1999/xhtml'>foo</p></foo> or even: <foo><zorglub xmlns='http://www.w3.org/1999/xhtml'>foo</zorglub></foo> Then the rendering reverts to HTML, irrespective of how far in the document the namespace declaration appears. This works using prefixes too. The namespace declaration on its own is not enough though.
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: Accepted Change Description: Opened up the possibility as requested, and also defined the specifics of the behaviour as noted in browsers. Rationale: It's already implemented, might as well be described correctly. https://github.com/w3c/html/commit/ab4b3dab8da4e150d18e7f514e2009d6f95381ca
(In reply to comment #7) That's great, thanks
Robin, how is your proposed solution compatible with incremental parsing?
(In reply to comment #9) > Robin, how is your proposed solution compatible with incremental parsing? As far as I could work out, here's what happens. If the document is clearly XML, and the root element isn't "html", then if it matches something for an external handler like Atom, it might be dispatched off to that. If however it doesn't match that the browser seems to just parse, parse, parse and render nothing. If at some point it suddenly sees an HTML/SVG/MathML element, it will render accordingly (applying the default UA style sheet and all). If it reaches the end without having seen one such element, then it shows the tree view. I tried this out by feeding browsers some megabytes-long document. I'm not sure how that could hurt incremental parsing, though I'd be happy to learn. It certainly hurts incremental rendering (of XML documents that have no HTML content) but this doesn't not strike me as a huge problem.
If that's what should happen, you should invoke the "render the XML tree" in the "The end" section. I'm not sure how to require that nothing be rendered while waiting for a supported element (which could be in a namespace other than HTML/SVG/MathML) or "the end", but that would have to be stated somehow. That the rendering section applies when there are supported elements is already the case. Saying that the rendering section "must" be followed means that the whole rendering section changes conformance class, since the rendering section has a special conformance class and avoids using "must". That said, did you test Opera wrt incremental rendering of the XML-tree view? Does it make sense to disallow incremental rendering of the XML tree?
Moreover, the spec now requires that the tree view be rendered even if there are style sheets present, which seems wrong.
Hixie submitted a patch for the related WHATWG bug 17980 : https://github.com/w3c/html/commit/e6649c31465e451b76aff1ac59eb7e29f31d6c3e Can you take care of merging it in?
(In reply to comment #13) > Hixie submitted a patch for the related WHATWG bug 17980 : > https://github.com/w3c/html/commit/e6649c31465e451b76aff1ac59eb7e29f31d6c3e > Can you take care of merging it in? I've merged it in. 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: Accepted Change Description: Applied WHAT change (describes the processing) Rationale: Useful addition
Thanks