This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Currently, section 9.1.2 of the specification limits the elements and attributes allowed as conforming in an HTML5 document to those listed in the HTML specification, those defined for MathML, and those defined for SVG. However, most of the SVG documents that would be copied and pasted into HTML5 documents incorporate elements from other namespaces, embedded into the SVG through the graphics tool (such as Inkscape), or added by the original artist and specifying artist name, Creative Commons licenses, and so on. Some of the metadata that can be embedded into the SVG document, using RDF/XML, may be required in order to use the SVG, and can't be removed, without violation of the Creative Commons license. These elements should be allowed in the SVG as long as they are well formed, and contained completely in the SVG/XML pasted into the HTML document. The example attached with this Bug demonstrates the type of external elements that can, and frequently do, appear with SVG. As tested with the Firefox nightly build, which supports SVG in HTML, allowing support for such elements has no adverse impact on parsing the document, or building the DOM.
Is this asking for the parser to support xmlns="" attributes?
Right now, if you have RDF/XML in the metadata element, or Inkscape names[aced attributes elsewhere in the SVG, Validator.nu throws some nasty errors. It does so, because, according to the validator's author, these are not allowed in SVG. I would like to see namespaces supported, if we're supporting XML, and SVG _is_ XML, but I'm not pushing for that here. What I'm asking for is something in the specification that the validity and conformance of the SVG is defined in the SVG specification. HTML5 conformance checkers should ignore namespaced elements they don't recognize. As for how namespaced elements are handled by the HTML parser, which would result in things like localname of dc:title, I'm not asking for a change in this behavior. I'll recommend people use SVGWeb if they realistically want to work with SVG/XML in an HTML document. For now, I don't want conformance errors triggered on perfectly valid SVG.
If you're asking for parsing namespaces, then that's a non-starter, since it would be far too easy for pages to end up stuck in one namespace in HTML5 UAs while working fine in legacy UAs. It would also be an incredible amount of complexity in the parser for more or less no benefit. This would be WONTFIX. If you're _not_ asking for that, but _are_ asking for the results of the parser to allow nodes that, when the same text is parsed as XML, would be allowed, then the nodes wouldn't be in the same namespace as they would be if parsed using an XML parser, so there'd be no way to allow them as far as I can tell we couldn't tell the difference between those nodes and illegitimate nodes. This would be NEEDSINFO: I'd need an explanation for how to fix it. If you're asking for nodes to be allowed when they are actually in the right namespace in the DOM, then that's already the case, since HTML5 just defers to SVG which allows namespaced content there. This would be WORKSFORME: it's already allowed. If you reopen this bug, please clarify which of the above you are asking for.
I have answered your note and question on namespaces, why do you keep bringing it up? My answer was clear: no, it is not about supporting namespaces. If I'm going to question the support for namespaces, will do so in a separate bug. "If you're asking for nodes to be allowed when they are actually in the right namespace in the DOM, then that's already the case, since HTML5 just defers to SVG which allows namespaced content there. This would be WORKSFORME: it's already allowed." This isn't communicated clearly in the document, leaving the HTML5 validator developers (and possibly others) in confusion about what is, or is not allowed, within the opening and closing SVG tags. I have been told, specifically, by the creator of Validator.nu that, according to the HTML5 specification, the use of dc:foo in SVG is "not allowed". Therefore your writing on what is, or is not, allowed in SVG is either too cryptic, too confusing, or both. A note spelling out, more or less what you just wrote in this comment, should be sufficient: the HTML5 specification treats SVG a a foreign object: what is, or is not valid, within that object is defined elsewhere. There should be no errors or warnings of conformance from an HTML5 validator about contents within the SVG tags.
Ian, perhaps you can consider http://lists.w3.org/Archives/Public/public-html/2009Sep/0623.html as part of this. A note pointing out that text/html documents such as <!DOCTYPE html> <title></title> <svg><foo xmlns="http://example.org/"/></svg> are non-conforming due to the fact that the <foo> element is placed in the SVG namespace, resulting in a DOM subtree which is not a conforming SVG DOM subtree, would be good to clarify the matter. (Assuming you aren't going to change the text/html parsing algorithm to construct a DOM that would contain a conforming SVG DOM subtree, or that you don't add any pre-processing rules that would allow that subtree to be conforming, which would be the two obvious ways to make the above conforming, AFAICT.) Similarly for <!DOCTYPE html> <title></title> <svg><a:foo xmlns:a="http://example.org/"/></svg> due to the element {http://www.w3.org/2000/svg}aU00003Afoo also causing the SVG content not being a conforming SVG DOM subtree.
(In reply to comment #4) > it is not about supporting namespaces [...] I have been told, specifically, by the > creator of Validator.nu that, according to the HTML5 specification, the use of > dc:foo in SVG is "not allowed". dc:foo is only not allowed because of the lack of support for namespaces. That's why I keep bringing up namespaces. Without namespaces, it's just an SVG element, and the SVG spec doesn't define it, so it's not allowed. > A note spelling out, more or less what you just wrote in this comment, should > be sufficient: the HTML5 specification treats SVG a a foreign object: what is, > or is not valid, within that object is defined elsewhere. There should be no > errors or warnings of conformance from an HTML5 validator about contents within > the SVG tags. (In reply to comment #5) > > A note pointing out that text/html documents such as > > <!DOCTYPE html> > <title></title> > <svg><foo xmlns="http://example.org/"/></svg> > > are non-conforming due to the fact that the <foo> element is placed in the SVG > namespace, resulting in a DOM subtree which is not a conforming SVG DOM > subtree, would be good to clarify the matter. Ok, I've added such a note.
Checked in as WHATWG revision r3956. Check-in comment: Add a note about how namespaces aren't supported. http://html5.org/tools/web-apps-tracker?from=3955&to=3956
(In reply to comment #6) > (In reply to comment #4) > > it is not about supporting namespaces [...] I have been told, specifically, by the > > creator of Validator.nu that, according to the HTML5 specification, the use of > > dc:foo in SVG is "not allowed". > > dc:foo is only not allowed because of the lack of support for namespaces. > That's why I keep bringing up namespaces. Without namespaces, it's just an SVG > element, and the SVG spec doesn't define it, so it's not allowed. > > This is not acceptable. If you're treating SVG as a foreign object, with its contents managed by that specification, that specification allows for namespaced elements. So either you're treating SVG as just another element in HTML5, in which case you have to completely list out every aspect of SVG that is supported in HTML5, of you have to treat it as a foreign object, and anything between the opening and closing tags is valid based on the SVG specifications, not HTML5. > > A note spelling out, more or less what you just wrote in this comment, should > > be sufficient: the HTML5 specification treats SVG a a foreign object: what is, > > or is not valid, within that object is defined elsewhere. There should be no > > errors or warnings of conformance from an HTML5 validator about contents within > > the SVG tags. > > (In reply to comment #5) > > > > A note pointing out that text/html documents such as > > > > <!DOCTYPE html> > > <title></title> > > <svg><foo xmlns="http://example.org/"/></svg> > > > > are non-conforming due to the fact that the <foo> element is placed in the SVG > > namespace, resulting in a DOM subtree which is not a conforming SVG DOM > > subtree, would be good to clarify the matter. > > Ok, I've added such a note. > That does not close this bug. You have not resolved the problem. You are in violation of your own design principles, when you don't consider that the majority of SVG in the wild has namespaced elements. You are also inconsistent, because in the specification, you mention when SVG is present, the parser creates both an HTML Document and an SVG Document, but then defer to the SVG specification about how SVG is to be parsed--at least, unless you're redefined what foreign object is. The SVG specification would allow namespaced elements, and would require a parser to handle them accordingly. So you have harmed the community by introducing a onerous burden on the authors and editors, and demand they either remove the namespaced elements (which would not be possible if these elements are licensing details, or embedded all throughout the SVG), or they accept several ugly, and incorrect "non-conforming" errors. You have also harmed the SVG specifications, by introducing a conflict between how SVG is controlled by these specs and how it is controlled in HTML. You have harmed the HTML5 specification by introducing conflicts and inconsistencies. .
I saw your change, in response to comment 5. You added: The HTML syntax does not support namespace declarations, even in foreign elements. For instance, consider the following HTML fragment: <p> <svg> <metadata> <!-- this is invalid --> <cdr:license xmlns:cdr="http://www.example.com/cdr/metadata" name="MIT"/> </metadata> </svg> </p> The innermost element, cdr:license, is actually in the SVG namespace, as the "xmlns:cdr" attribute has no effect (unlike in XML). In fact, as the comment in the fragment above says, the fragment is actually non-conforming. This is because the SVG specification does not define any elements called "cdr:license" in the SVG namespace. --- This means every legitimate use of namespaces in an SVG document embedded into HTML will now generate a conformance error. This is NOT allowing the SVG specification to determine what is, or is not, valid within SVG.
Since a lot of SVG content out there will have 'unrecognized-from-a-HTML5-point-of-view' elements and attributes, I would like to propose that we modify the validator to provide a special option: [ ] Ignore foreign attributes and elements inside SVG/MathML This means that when the parser's insertion mode is "in foreign content" that it will ignore unrecognized elements and attributes (i.e. will not report errors or warnings).
Shelley: So you _are_ asking for the parser to parse namespaces? Jeff: That seems reasonable, but out of scope for the spec. I recommend raising that with your favourite validator's vendor.
Ian: Thinking a little more - why couldn't these errors be dropped when the parser's insertion mode is "in foreign content" i.e. a change in the parser spec? What's the value in reporting those errors? Is it to help people who misspell 'rect' etc?
(In reply to comment #12) > Ian: Thinking a little more - why couldn't these errors be dropped when the > parser's insertion mode is "in foreign content" i.e. a change in the parser > spec? The HTML spec doesn't say that these are errors, the SVG spec does. The HTML spec is only relevant here because it is the spec that is failing to put the elements in the expected namespaces. > What's the value in reporting those errors? Is it to help people who misspell > 'rect' etc? Yes.
(In reply to comment #13) > (In reply to comment #12) > > Ian: Thinking a little more - why couldn't these errors be dropped when the > > parser's insertion mode is "in foreign content" i.e. a change in the parser > > spec? > > The HTML spec doesn't say that these are errors, the SVG spec does. The HTML > spec is only relevant here because it is the spec that is failing to put the > elements in the expected namespaces. > > > > What's the value in reporting those errors? Is it to help people who misspell > > 'rect' etc? > > Yes. > Then one can assume that if elements are referenced without a namespace they're from the SVG namespace, and handled accordingly. Frankly, though, such validation should occur with an SVG specific validator, not one that's HTML5. That's not what this bug is about. This bug is deferring to the SVG specification about what is or is not conforming. The HTML5 specification should ignore namespaced contents of the SVG element. That's what the SVG specification states: they should be ignored. Insert into the HTML5 specification: The SVG specification states that namespaced elements not part of the SVG specification, and not included in a foreignObject element should be ignored. These namespaced elements will be ignored in HTML5. They are considered neither conforming nor non-conforming from an HTML5 perspective. Then all validator creators, not just the one, will understand what to do when it comes across unknown namespaced elements within the SVG element. They will ignore them.
> Insert into the HTML5 specification: > > The SVG specification states that namespaced elements not part of the SVG > specification, and not included in a foreignObject element should be ignored. > These namespaced elements will be ignored in HTML5. They are considered neither > conforming nor non-conforming from an HTML5 perspective. I've added the following text: "The SVG specification states that elements that are not in the SVG namespace, that are in SVG fragments, and that are not included in a foreignObject element, are to be ignored. Similarly, _this_ specification does not define any processing for elements in SVG fragments that are not in the HTML namespace; they are considered neither conforming nor non-conforming from the perspective of this specification." I changed "namespaced elements" to "elements that are not in the SVG namespace" because all elements are namespaced elements. I added "that are in SVG fragments" because SVG doesn't make claims about elements outside of SVG fragments. I changed your second sentence to be more precise in its meaning; in particular, I don't want to imply that HTML elements can be used in SVG in manners that violate the rest of the HTML spec. I changed "HTML5" to "this specification" throughout to make future maintenance easier. Please let me know if that's acceptable.
Checked in as WHATWG revision r3977. Check-in comment: Clarify that HTML doesn't override SVG. http://html5.org/tools/web-apps-tracker?from=3976&to=3977
(In reply to comment #15) > > Insert into the HTML5 specification: > > > > The SVG specification states that namespaced elements not part of the SVG > > specification, and not included in a foreignObject element should be ignored. > > These namespaced elements will be ignored in HTML5. They are considered neither > > conforming nor non-conforming from an HTML5 perspective. > > I've added the following text: > > "The SVG specification states that elements that are not in the SVG namespace, > that are in SVG fragments, and that are not included in a foreignObject > element, are to be ignored. Similarly, _this_ specification does not define any > processing for elements in SVG fragments that are not in the HTML namespace; > they are considered neither conforming nor non-conforming from the perspective > of this specification." > > I changed "namespaced elements" to "elements that are not in the SVG namespace" > because all elements are namespaced elements. > I added "that are in SVG fragments" because SVG doesn't make claims about > elements outside of SVG fragments. > I changed your second sentence to be more precise in its meaning; in > particular, I don't want to imply that HTML elements can be used in SVG in > manners that violate the rest of the HTML spec. > I changed "HTML5" to "this specification" throughout to make future maintenance > easier. > > Please let me know if that's acceptable. > I think it's a concern to paraphrase what the SVG spec says, because SVG could change in the future. And if you don't use what's exactly in SVG, it could create confusion. A better approach is to just make a statement deferring to the SVG specification as regards to how foreign namespace elements and attributes are handled. For instance, there may now be ambiguity in the specification as regards to the foreign namespaced elements and attributes. SVG 1.1 has the following: SVG allows inclusion of elements from foreign namespaces anywhere with the SVG content. In general, the SVG user agent will include the unknown elements in the DOM but will otherwise ignore unknown elements. (The notable exception is described under Embedding Foreign Object Types.) Additionally, SVG allows inclusion of attributes from foreign namespaces on any SVG element. The SVG user agent will include unknown attributes in the DOM but with otherwise ignore unknown attributes. -- Your statement doesn't mention the DOM. It may seem like I'm picking nits, but it was important to provide that additional information to ensure the elements and attributes were picked up in the SVG DOM, and the same applies to SVG within HTML. This may be stated elsewhere in the document, but I want to make sure there's no confusion in this regard. Now, I am aware that when SVG is inline, there is no SVGDocument, the SVG becomes part of the HTMLDocument. I know this means, in HTML, that the foreign namespaced elements and attributes would be parsed as HTML. I am aware that this means that the namespaces would not be parsed, and that attributes and elements would become part of the SVG namespace, and their localnames would be recorded in the DOM as "dc:foo". I am not contesting this, in this bug. Other than these nits, I think we're very close to a equitable solution. I'm sorry to have to reopen the bug, but it's the only way I know of to suggest an additional edit.
> > "The SVG specification states that elements that are not in the SVG namespace, > > that are in SVG fragments, and that are not included in a foreignObject > > element, are to be ignored. Similarly, _this_ specification does not define any > > processing for elements in SVG fragments that are not in the HTML namespace; > > they are considered neither conforming nor non-conforming from the perspective > > of this specification." > > I think it's a concern to paraphrase what the SVG spec says, because SVG could > change in the future. And if you don't use what's exactly in SVG, it could > create confusion. Ok... I was just trying to use your proposal. I've removed the paraphrasing. I've also not quoted the text exactly since it seems that is even more prone to being affected by the SVG spec changing in the future. > A better approach is to just make a statement deferring to the SVG > specification as regards to how foreign namespace elements and attributes are > handled. Since SVG doesn't say how to handle foreign namespaced elements and attributes, deferring to SVG seems like a roundabout way of saying that HTML doesn't say how to handle foreign namespaced elements and attributes either. Is that really valuable? > For instance, there may now be ambiguity in the specification as > regards to the foreign namespaced elements and attributes. Could you elaborate on this? I don't see what is ambiguous. > Your statement doesn't mention the DOM. I have added an explicit mention of the DOM. > It may seem like I'm picking nits, but > it was important to provide that additional information to ensure the elements > and attributes were picked up in the SVG DOM, and the same applies to SVG > within HTML. I've no idea what that means. Surely the parser section unambiguously defines exactly what ends up in the DOM, such that there is no need for anything additional that would ensure that any elements and attributes are "picked up". It seems like adding additional text that sounds like parsing requirements, but outside the parsing section, would be misleading. The text is now: "The SVG specification includes requirements regarding the handling of elements in the DOM that are not in the SVG namespace, that are in SVG fragments, and that are not included in a foreignObject element. This specification does not define any processing for elements in SVG fragments that are not in the HTML namespace; they are considered neither conforming nor non-conforming from the perspective of this specification." Please feel free to reopen this bug if you would like further tweaks.
Checked in as WHATWG revision r4009. Check-in comment: Try some tweaks Shelley suggested. http://html5.org/tools/web-apps-tracker?from=4008&to=4009
believe the new namespace and distributed extensibility proposal would have significant impact on this specific bug, and handling namespaces in SVG, generally. Since this is new information, I'm re-opening this bug, and would like it tied to the proposal. http://lists.w3.org/Archives/Public/public-html/2009Sep/att-1216/MicrosoftDistributedExtensibilitySubmission.htm
What changes are being requested that would lead to this bug being resolved?
I want support for namespaced elements in SVG. At the DOM Level, and within the spec in such a way that valid namespaced elements do not trigger errors or warnings in validators. Either that, or I would to escalate this bug to the Issue Tracker.
I believe what I'm asking for is clear enough: support for namespaced elements in foreign content, such as MathML and SVG, as well as accurate support for these elements within the DOM for the foreign content.
(In reply to comment #4) > no, it is not about supporting namespaces. If I'm going to question > the support for namespaces, will do so in a separate bug. (In reply to comment #23) > I believe what I'm asking for is clear enough: support for namespaced > elements in foreign content, such as MathML and SVG (In reply to comment #22) > I would to escalate this bug to the Issue Tracker. No, you haven't made your request clear at all. I've tried to add to the spec the exact text you've proposed. I've tried to tweak the text multiple times in response to your complaints that the text you proposed isn't adequate. You have contradicted yourself multiple times and I really haven't the faintest idea what you actually want, what problem you're trying to solve, or what you would consider an acceptable solution other than escalating this to a tracker issue. So: 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 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: I cannot understand the request despite repeated efforts. Shelley apparently just wants an excuse to raise a tracker issue.
I'll be opening a new, more tightly focused bug on this topic.