9859 2010-06-05 05:39:51 +0000 add document-conformance constraints for documents that contain SVG or MathML content that in turn contains HTML content 2010-10-04 14:48:54 +0000 1 1 1 Unclassified HTML WG pre-LC1 HTML5 spec (editor: Ian Hickson) unspecified PC All RESOLVED WONTFIX P2 normal --- 1 mike ian hsivonen ian mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 35983 0 mike 2010-06-05 05:39:51 +0000 I note that the 'The "in foreign content" insertion mode' subsection of the "Tree construction" section defines as a parse error any instance of 'A start tag whose tag name is one of: "b", "big", "blockquote", "body", "br", "center",', etc., when the parser is in the "in foreign content" insertion mode. http://dev.w3.org/html5/spec/tokenization.html#parsing-main-inforeign That's all great, but the author view of the spec doesn't provide any corresponding requirements on documents/authors when they are creating documents that contain SVG and MathML content. So I think it would be helpful if the spec could state something like, 'Documents [meaning serialized documents, not parsed DOM representations] must not have SVG or MathML content that contains any of the following elements: "b", "big", "blockquote", "body", "br", "center",' etc. I realize that a parsed document in memory is not going to contain such instances. I mean for this suggestion to apply to guidance for authors on how to produce conformant documents. 35984 1 mike 2010-06-05 05:50:23 +0000 I'm looking at this test case: http://validator.nu/?doc=https%3A%2F%2Feyeasme.com%2FJoe%2FMathML%2FHTML5%2Fextras.html&showsource=yes#l230c87 ...which is originally from http://www.mozilla.org/projects/mathml/demo/extras.xhtml validation on it fails -- actually, proper error-free parsing of it fails -- because it has an HTML img element within a MathML annotation-xml element, as far as I can tell but HTML img within MathML annotation-xml seems to be valid as far as MathML is concerned, and as far as validator.nu is concerned, if it's served with an XML MIME type - http://validator.nu/?doc=https%3A%2F%2Feyeasme.com%2FJoe%2FMathML%2FHTML5%2Fextras.xhtml&showsource=yes It seems the the only case where it's not conformant is when it's served as text/html 36009 2 zcorpan 2010-06-07 03:40:26 +0000 "A start tag whose tag name is "svg", if the current node is an annotation-xml element in the MathML namespace." The HTML5 parser only allows <svg> or MathML in <annotation-xml>. Not HTML. <span> will be in MathML namespace. We could change the parser to allow HTML there (like it allows HTML in MathML <mi>), but then it would break MathML in <annotation-xml>. The MathML spec has an example with MathML in <annotation-xml>. Maybe we need a special tag that enables HTML in <annotation-xml>? <div>? It means MathML can't have a future element called <div>. "A start tag whose tag name is "svg" or "div" if the current node is an annotation-xml element in the MathML namespace." However... The XHTML version doesn't use <annotation-xml> at all. Why does the HTML version? Shouldn't it use <mn> or <mtext> instead? 36011 3 mike 2010-06-07 05:12:00 +0000 (In reply to comment #2) > "A start tag whose tag name is "svg", if the current node is an annotation-xml > element in the MathML namespace." > > The HTML5 parser only allows <svg> or MathML in <annotation-xml>. Not HTML. > <span> will be in MathML namespace. I see now... I had not noticed that previously. > However... The XHTML version doesn't use <annotation-xml> at all. Why does the > HTML version? Shouldn't it use <mn> or <mtext> instead? I also hadn't noticed that the original source did not use <annotation-xml>.. I'll ask the person who originally reported if why he made that change 36012 4 hsivonen 2010-06-07 06:55:06 +0000 Could be my fault for making an incorrect statement about annotation-xml on the Mozilla Hacks blog. 36060 5 mike 2010-06-09 02:29:24 +0000 FYI, I opened a related bug, bug 9887, "parsing algorithm should allow HTML content in MathML <annotation-xml>" 36136 6 mike 2010-06-14 01:34:47 +0000 I had some offlist discussion about where HTML elements should be allowed in MathML content, and that leads me to suggest that it should be restricted to <mtext> elements. I realize that the parsing algorithm also processes HTML content correctly if it's in <mi>, <mn>, <mo>, and <ms> elements, but I think this is a case where it makes sense for the document-conformance requirements to be stricter than what the parsing algorithm allows 36137 7 zcorpan 2010-06-14 06:21:47 +0000 > I think > this is a case where it makes sense for the document-conformance requirements > to be stricter than what the parsing algorithm allows Why? Is this something that will change over time (i.e. do you think it will make sense to allow HTML in <mn> in the future)? 36138 8 mike 2010-06-14 06:37:21 +0000 (In reply to comment #7) > > I think > > this is a case where it makes sense for the document-conformance requirements > > to be stricter than what the parsing algorithm allows > > Why? Is this something that will change over time (i.e. do you think it will > make sense to allow HTML in <mn> in the future)? I don't think it will make sense to allow HTML in <mn> in the future, no. But from what I've gleaned both about MathML semantics and that MathML tools situation, putting HTML into <mn> (or any of the "token elements" except for <mtext>) is both not a good match for MathML semantics and also a potential problem for other non-browser MathML processing tools. I think the case is that the existing tools don't necessarily expect to do any processing at all of <mtext> contents -- and so any non-MathML-namespace markup they find in <mtext> is not going to cause them any processing failures -- whereas some tools do not expect such markup in <mn>, etc., so it may cause them some processing failures. Anyway, I think what we'll eventually need is for someone knowledgeable about MathML semantic differences and the MathML tool situation -- preferably somebody from the Math WG -- to post comment here with some more details. 38036 9 ian 2010-08-27 20:46:35 +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: Rejected Change Description: no spec change Rationale: It's already the case that you can't legally put those elements the places where they cause problems, by virtue of them not being valid in SVG and MathML.