15180 2011-12-14 12:48:07 +0000 Default handling of non-XHTML XML docs is under-/un- specified 2012-12-06 11:53:12 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC Windows NT CLOSED FIXED P2 normal --- 1 ht robin eoconnor ian julian.reschke mike public-html-admin public-html-wg-issue-tracking robin silviapfeiffer1 public-html-bugzilla oldest_to_newest 61543 0 ht 2011-12-14 12:48:07 +0000 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. 61544 1 julian.reschke 2011-12-14 13:38:48 +0000 This obviously should *allow* UAs to process a stylesheet link header field. 61545 2 ht 2011-12-14 15:09:07 +0000 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', . . ." 63230 3 contributor 2012-01-28 18:29:01 +0000 Checked in as WHATWG revision r6928. Check-in comment: copypasta http://html5.org/tools/web-apps-tracker?from=6927&to=6928 63231 4 ian 2012-01-28 18:29:59 +0000 Apologies, that was intended for bug 15177. 70422 5 contributor 2012-07-18 07:28:01 +0000 This bug was cloned to create bug 17980 as part of operation convergence. 73306 6 robin 2012-09-06 14:32:52 +0000 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. 73322 7 robin 2012-09-06 15:56:04 +0000 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 73326 8 ht 2012-09-06 16:16:07 +0000 (In reply to comment #7) That's great, thanks 73334 9 eoconnor 2012-09-06 16:59:33 +0000 Robin, how is your proposed solution compatible with incremental parsing? 73339 10 robin 2012-09-06 17:17:49 +0000 (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. 73364 11 zcorpan 2012-09-06 20:29:38 +0000 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? 73366 12 zcorpan 2012-09-06 20:35:59 +0000 Moreover, the spec now requires that the tree view be rendered even if there are style sheets present, which seems wrong. 78996 13 silviapfeiffer1 2012-11-28 15:37:16 +0000 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? 79546 14 robin 2012-12-06 11:25:30 +0000 (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 79548 15 ht 2012-12-06 11:53:12 +0000 Thanks