This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
+++ This bug was initially created as a clone of Bug #7510 +++ I cloned the bug since this is a slightly different issue from what Shelley raised. (In reply to comment #15 of bug 7510) > "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." This seems strange to me. Defining whether elements are conforming or not is just a shorthand way of defining conformance of the document in which those elements reside, right? So we're really leaving the conformance of <!DOCTYPE html> <title></title> <svg><yowsers/></svg> undefined? What should an HTML5 validator report? Is the conformance of the document dependent on whether the validator you are targetting supports SVG? I do think that HTML5 needs to define whether any document is conforming or not. Also, the text you added earlier: This is because the SVG specification does not define any elements called "cdr:license" in the SVG namespace. is not quite correct. Well, according to the change referenced in comment #15, it is neither conforming nor non-conforming. But assuming that the conformance of the HTML document fragment is somehow dependent on the conformance of the SVG fragment as defined by SVG, then it is non-conforming because SVG does not define an element named cdrU00003Alicense in the SVG namespace.
> This seems strange to me. Defining whether elements are conforming or not is > just a shorthand way of defining conformance of the document in which those > elements reside, right? So we're really leaving the conformance of > > <!DOCTYPE html> > <title></title> > <svg><yowsers/></svg> > > undefined? Not at all. We're just saying that the conformance of that document is the same as the conformance of the following XML file: <html xmlns="http://www.w3.org/1999/xhtml"><head><title></title> </head><body><svg xmlns="http://www.w3.org/2000/svg"><yowsers/></svg></body></html> The conformance of this is defined in a number of specs, including most notably HTML and SVG. It's not conforming, because SVG says that you can't use the element "yowsers" from the SVG namespace as a child of the <svg> element. > What should an HTML5 validator report? Is the conformance of the > document dependent on whether the validator you are targetting supports SVG? No, the conformance of the document has nothing to do with the validator. A document is conforming or not even in the absence of any validation tool. Whether the validator complains about the <html> element, the <svg> element, or the <yowsers> element, depends on whether it supports only SVG, only HTML, or both. > Also, the text you added earlier: > > This is because the SVG specification does not define any elements > called "cdr:license" in the SVG namespace. > > is not quite correct. Well, according to the change referenced in comment #15, > it is neither conforming nor non-conforming. No, it is non-conforming. SVG doesn't allow SVG elements that it doesn't define, and it doesn't define an element with the namespace "http://www.w3.org/2000/svg" and the local name "cdr:license". (Note that there is no prefix here. The local name has a colon.) > But assuming that the conformance > of the HTML document fragment is somehow dependent on the conformance of the > SVG fragment as defined by SVG, then it is non-conforming because SVG does not > define an element named cdrU00003Alicense in the SVG namespace. Correct. Marking WORKSFORME since we seem to be on the same page here.
(In reply to comment #1) > > So we're really leaving the conformance of > > > > <!DOCTYPE html> > > <title></title> > > <svg><yowsers/></svg> > > > > undefined? > > Not at all. We're just saying that the conformance of that document is the > same as the conformance of the following XML file: > > <html xmlns="http://www.w3.org/1999/xhtml"><head><title></title> > </head><body><svg > xmlns="http://www.w3.org/2000/svg"><yowsers/></svg></body></html> I have the same issue with the conformance of the above not being well defined; this bug just happened to be using text/html syntax. > The conformance of this is defined in a number of specs, including most > notably HTML and SVG. It's not conforming, because SVG says that you can't > use the element "yowsers" from the SVG namespace as a child of the <svg> > element. So HTML5 doesn't define a "valid HTML5 document" conformance class, but just provides a number of conformance assertions that should apply in any document? I didn't really think of it like that. Can you point me to where in the spec it says this? What you probably can guess I think is missing is an explicit hook to say that a text/html document represented by the string '<!DOCTYPE html><title></title><svg><yowsers/></svg>' is non-conforming. > > What should an HTML5 validator report? Is the conformance of the > > document dependent on whether the validator you are targetting supports SVG? > > No, the conformance of the document has nothing to do with the validator. A > document is conforming or not even in the absence of any validation tool. OK, that's good. > Whether the validator complains about the <html> element, the <svg> element, or > the <yowsers> element, depends on whether it supports only SVG, only HTML, or > both. All right, so the validator might not complain about these conformance problems because it doesn't support SVG, yet they are still indeed conformance problems.
If we take some arbitrary SVG XML document in the wild that includes a properly namespaced element and paste it into an HTML5 text/html document - I want to avoid needless conformance errors when running the HTML5 document through a validator. Ideally, I want that <sodipodi:namedView> element to be ignored since it wasn't an error in the XML context. The browser will ignore it. I want the validator to also ignore it. Is this possible? I think Ian's change now takes the responsibility of defining conformance criteria of elements within an <svg> element out of the HTML5 document and says it's the SVG specification's responsibility to define conformance. Seems sensible. For SVG-in-XML, the conformance of a particular document is well-defined by the SVG spec. It's basically XML and the DTD, right? For SVG-in-HTML, things are a different story. The SVG specification does not cover conformance of SVG-in-HTML markup really. What document says that an attribute with the qualified name "xlink:href" should be considered in the Xlink namespace? What about xlink:title and others? Where should it be described that <Svg><Rect WIDTH=50 heighT=100 fill=red> is valid SVG-in-HTML? Is that still in the HTML5 spec? Would it be crazy to say that conformance criteria of SVG-in-HTML should try to reconstitute unrecognized elements into their namespaces? i.e. if an unrecognized element with a qualified name of 'sodipodi:namedView' is found, then look for a xlink:sodipodi attribute, etc? Or would it be crazy to say that unrecognized elements in SVG-in-HTML should just be ignored and considered neither conforming or nonconforming?
(In reply to comment #3) > If we take some arbitrary SVG XML document in the wild that includes a properly > namespaced element and paste it into an HTML5 text/html document - I want to > avoid needless conformance errors when running the HTML5 document through a > validator. Ideally, I want that <sodipodi:namedView> element to be ignored > since it wasn't an error in the XML context. The browser will ignore it. I > want the validator to also ignore it. Is this possible? One problem is that, after the text/html document is parsed, start tags with colons in their names result in elements with the string "U00003A" being created. Once parsed, if the validator is just looking at the DOM, it is impossible to determine whether the string "<dc:title>" was in the document or whether it was "<dcU00003Atitle>". If you want to define that the former is conforming while the latter is non-conforming, then you need information about what the document source text looked like before the DOM was produced. Not impossible, but a layering violation of a sort. > I think Ian's change now takes the responsibility of defining conformance > criteria of elements within an <svg> element out of the HTML5 document and says > it's the SVG specification's responsibility to define conformance. Seems > sensible. That does seem sensible. Although my quibbling is that the conformance of an HTML document isn't really, explicitly defined to defer to SVG like this. > For SVG-in-XML, the conformance of a particular document is well-defined by the > SVG spec. It's basically XML and the DTD, right? Right, with some pre-processing steps: http://dev.w3.org/SVG/profiles/1.1F2/publish/conform.html#ConformingSVGDocuments > For SVG-in-HTML, things are a different story. The SVG specification does not > cover conformance of SVG-in-HTML markup really. Correct. It defines conformance of XML document fragments in isolation, as well as (just recently) DOM subtrees in isolation. > What document says that an attribute with the qualified name "xlink:href" > should be considered in the Xlink namespace? What about xlink:title and > others? You mean as the result of parsing text/html? HTML5 defines that. > Where should it be described that <Svg><Rect WIDTH=50 heighT=100 fill=red> is > valid SVG-in-HTML? Is that still in the HTML5 spec? It would be a combination of the HTML5 spec and the SVG spec that defines that. The HTML5 part talks about how a given string of characters gets parsed in text/html (i.e., that the "<Svg>" part results in a {http://www.w3.org/2000/svg}svg element being created, etc.), and SVG defines that a {http://www.w3.org/2000/svg}rect is allowed to be a child of a {http://www.w3.org/2000/svg}svg, and that its attributes width="", height="" and fill="" have to use some particular syntax. > Would it be crazy to say that conformance criteria of SVG-in-HTML should try to > reconstitute unrecognized elements into their namespaces? That could be done in a few ways: * HTML5 pretty much implements something like Namespaces in XML support in the text/html parser, and so reconstitution isn't required (as the elements would get placed in their non-SVG namespaces automatically). I don't think Ian is inclined to do this. * SVG could add a new conformance class, "Conforming SVG DOM Subtree That Came From Parsing text/html" (or so), which does funny things with elements that have names like "dcU00003Atitle" in the SVG namespace and attributes on ancestor elements that have names like "xmlns:dc" in the null namespace. This seems a bit hacky. * SVG could add a new conformance class, "Conforming SVG DOM Subtree That Came From Parsing text/html" which allows elements in the SVG namespace that aren't defined in the SVG spec, whose names contain the substring "U0003A". Also a bit of a hack. > i.e. if an unrecognized element with a qualified name of 'sodipodi:namedView' > is found, then look for a xlink:sodipodi attribute, etc? > > Or would it be crazy to say that unrecognized elements in SVG-in-HTML should > just be ignored and considered neither conforming or nonconforming? That'd be another way; HTML5 doesn't just defer to SVG for the entire SVG DOM subtree as is, but first "massages" it into a form that removes those elements before invoking the "Conforming SVG DOM Subtree" concept.
> I have the same issue with the conformance of the above not being well defined; > this bug just happened to be using text/html syntax. The conformance of both is well-defined. > So HTML5 doesn't define a "valid HTML5 document" conformance class, but just > provides a number of conformance assertions that should apply in any document? HTML5 defines two things of relevance: the conformance requirements for the syntax of documents transmitted as text/html, and the conformance requirements for the content of elements in the HTML namespace, regardless of whether they are found (text/html, XML, DOM, something else). > I didn't really think of it like that. Can you point me to where in the spec > it says this? I'm not exactly sure what you want a pointer to. Could you elaborate? > What you probably can guess I think is missing is an explicit hook to say that > a text/html document represented by the string '<!DOCTYPE > html><title></title><svg><yowsers/></svg>' is non-conforming. The "Writing HTML documents" section: http://www.whatwg.org/specs/web-apps/current-work/#writing ...describes the syntax of text/html, which gives the the interpretation of what the above string represents as a (DOM) tree. The HTML and SVG specs together define whether that tree is conforming. (In reply to comment #3) > If we take some arbitrary SVG XML document in the wild that includes a properly > namespaced element and paste it into an HTML5 text/html document - I want to > avoid needless conformance errors when running the HTML5 document through a > validator. There won't be any needless ones. There'll be several complaining that the document you pasted doesn't mean what you think it means, though. These aren't needless, they're actually quite important — we don't want, e.g, someone writing a script that works with their SVG in text/html but suddenly fails when they reserialize it to XML. It's bad enough that we're allowing document.write() and so forth. > Ideally, I want that <sodipodi:namedView> element to be ignored > since it wasn't an error in the XML context. The browser will ignore it. I > want the validator to also ignore it. Is this possible? Not without HTML parsing namespace declarations, and I really don't think we want to go there. > For SVG-in-HTML, things are a different story. The SVG specification does not > cover conformance of SVG-in-HTML markup really. SVG-in-HTML is the same as SVG-in-dynamically-generated-DOM-trees, as far as conformance goes. So unless SVG also doesn't define conformance for those, then this is all well-defined. (If it doesn't define conformance for those, then there are bigger problems than text/html.) > What document says that an attribute with the qualified name "xlink:href" > should be considered in the Xlink namespace? What about xlink:title and > others? In text/html, HTML5 hardcodes those strings to the right namespaces. > Where should it be described that <Svg><Rect WIDTH=50 heighT=100 fill=red> is > valid SVG-in-HTML? Is that still in the HTML5 spec? It's valid because the syntax results in a DOM tree that is isomorphic with a DOM tree that would be considered a valid SVG fragment. > Would it be crazy to say that conformance criteria of SVG-in-HTML should try to > reconstitute unrecognized elements into their namespaces? If you mean that HTML should support namespace declarations, then I don't think it's crazy, but I don't think it's a good idea, either. It's not clear how it would work in a backwards-compatible manner. It would also mean dragging the whole rebindable-prefix mess into text/html, which I really think would do the Web authoring community a big disservice. > Or would it be crazy to say that unrecognized elements in SVG-in-HTML should > just be ignored and considered neither conforming or nonconforming? That's an SVG question, as far as I can tell. I don't think we want different conformance criteria for DOMs that came from text/html vs DOMs that came from XML or DOMs that were generated from script or from some other source. (In reply to comment #4) > One problem is that, after the text/html document is parsed, start tags with > colons in their names result in elements with the string "U00003A" being > created. Not necessarily; the U00003A stuff is an optional conversion step for architectures that don't support node names that aren't well-formed XML. I wouldn't expect a Web browser to do that conversion step, for instance. > Once parsed, if the validator is just looking at the DOM, it is > impossible to determine whether the string "<dc:title>" was in the document or > whether it was "<dcU00003Atitle>". Assuming no script, and assuming the input is text/html, then it is impossible to generate an element with the name "<dcU00003Atitle>" in the absence of this conversion step. > "Conforming SVG DOM Subtree That Came From Parsing text/html" I strongly recommend against making conformance classes that mean that reserializing a text/html document to XML would cause the document to stop being conforming. (There's a few cases of this in text/html, but they're all legacy that I'm trying to minimise the damage from.) I also recommend against making it conforming to have elements in the DOM that aren't what the author thinks they are, because that will do a disservice to the author. The point of conformance is to catch that kind of mistake.
> (In reply to comment #3) > > If we take some arbitrary SVG XML document in the wild that includes a properly > > namespaced element and paste it into an HTML5 text/html document - I want to > > avoid needless conformance errors when running the HTML5 document through a > > validator. > > There won't be any needless ones. There'll be several complaining that the > document you pasted doesn't mean what you think it means, though. These aren't > needless, they're actually quite important — we don't want, e.g, someone > writing a script that works with their SVG in text/html but suddenly fails when > they reserialize it to XML. It's bad enough that we're allowing > document.write() and so forth. > But there is no basis for issuing these warnings. No error has occurred. There is nothing in the specification that can be used as a basis for these warnings. I understand about the differences in DOM and parsing, but if we litter the results with dozens, hundreds of warnings, the validator is effectively useless. > > > Ideally, I want that <sodipodi:namedView> element to be ignored > > since it wasn't an error in the XML context. The browser will ignore it. I > > want the validator to also ignore it. Is this possible? > > Not without HTML parsing namespace declarations, and I really don't think we > want to go there. > Unfortunately, HTML5 does not provide extensibility in this regard. The days when we could extend a specification, or create a new profile, are gone. We're now facing a future of never ending conformance warnings and errors. > > > For SVG-in-HTML, things are a different story. The SVG specification does not > > cover conformance of SVG-in-HTML markup really. > > SVG-in-HTML is the same as SVG-in-dynamically-generated-DOM-trees, as far as > conformance goes. So unless SVG also doesn't define conformance for those, then > this is all well-defined. (If it doesn't define conformance for those, then > there are bigger problems than text/html.) > > > > What document says that an attribute with the qualified name "xlink:href" > > should be considered in the Xlink namespace? What about xlink:title and > > others? > > In text/html, HTML5 hardcodes those strings to the right namespaces. > > > > Where should it be described that <Svg><Rect WIDTH=50 heighT=100 fill=red> is > > valid SVG-in-HTML? Is that still in the HTML5 spec? > > It's valid because the syntax results in a DOM tree that is isomorphic with a > DOM tree that would be considered a valid SVG fragment. > > See, now that is selling out the markup in order to support the DOM. I think this is wrong, and unnecessary. If you're deferring to SVG about what is conforming in SVG, then that should include quoting attributes, et al. Unfortunately, though, crappy HTML rules have to apply, since it's being parsed as HTML. I'm not saying you should change it. I'm just saying it's an inelegant approach. > > Would it be crazy to say that conformance criteria of SVG-in-HTML should try to > > reconstitute unrecognized elements into their namespaces? > > If you mean that HTML should support namespace declarations, then I don't think > it's crazy, but I don't think it's a good idea, either. It's not clear how it > would work in a backwards-compatible manner. It would also mean dragging the > whole rebindable-prefix mess into text/html, which I really think would do the > Web authoring community a big disservice. > Eventually you're going to have to face this in some way, in one of these bugs, in some issue. It will not go away. > > > Or would it be crazy to say that unrecognized elements in SVG-in-HTML should > > just be ignored and considered neither conforming or nonconforming? > > That's an SVG question, as far as I can tell. I don't think we want different > conformance criteria for DOMs that came from text/html vs DOMs that came from > XML or DOMs that were generated from script or from some other source. > I believe you answered that in the other bug, by stating that you're deferring to SVG in how these elements and attributes are handled.
> > > If we take some arbitrary SVG XML document in the wild that includes a properly > > > namespaced element and paste it into an HTML5 text/html document - I want to > > > avoid needless conformance errors when running the HTML5 document through a > > > validator. > > > > There won't be any needless ones. There'll be several complaining that the > > document you pasted doesn't mean what you think it means, though. These aren't > > needless, they're actually quite important — we don't want, e.g, someone > > writing a script that works with their SVG in text/html but suddenly fails when > > they reserialize it to XML. It's bad enough that we're allowing > > document.write() and so forth. > > But there is no basis for issuing these warnings. They're not warnings, they're errors from violating the SVG schema by having elements in the SVG namespace that the SVG spec doesn't allow. > No error has occurred. An element from the SVG namespace that isn't defined to be allowed at that position has been placed at that position. That's an error. > There is nothing in the specification that can be used as a basis for these > warnings. If you believe this, and believe this to be a good thing, then this bug should be filed with your validator vendor, not with the spec. (I do not believe that statement to be true, personally.) > I understand about the differences in DOM and parsing, but if we litter the > results with dozens, hundreds of warnings, the validator is effectively > useless. Only one error need be shown here. The number of errors shown is a UI issue; please file such bugs with your validator vendor. > > > Ideally, I want that <sodipodi:namedView> element to be ignored > > > since it wasn't an error in the XML context. The browser will ignore it. I > > > want the validator to also ignore it. Is this possible? > > > > Not without HTML parsing namespace declarations, and I really don't think we > > want to go there. > > Unfortunately, HTML5 does not provide extensibility in this regard. The days > when we could extend a specification, or create a new profile, are gone. We're > now facing a future of never ending conformance warnings and errors. HTML5's extension story in this regard is more detailed than HTML4's, but this is not the place for me to expound the benefits of HTML5's extensibility story. I will just refer you to the FAQ: http://wiki.whatwg.org/wiki/FAQ#HTML5_should_support_a_way_for_anyone_to_invent_new_elements.21 > > > Where should it be described that <Svg><Rect WIDTH=50 heighT=100 fill=red> is > > > valid SVG-in-HTML? Is that still in the HTML5 spec? > > > > It's valid because the syntax results in a DOM tree that is isomorphic with a > > DOM tree that would be considered a valid SVG fragment. > > See, now that is selling out the markup in order to support the DOM. I think > this is wrong, and unnecessary. I have no idea what this means. > If you're deferring to SVG about what is conforming in SVG, then that should > include quoting attributes, et al. HTML5 defers to SVG about what is a conforming SVG DOM; it defines its own syntax. This is just like how the XML spec defers (implicitly) to SVG for the conformance of the resulting Infoset, but defines its own syntax. > Unfortunately, though, crappy HTML rules > have to apply, since it's being parsed as HTML. I'm not saying you should > change it. I'm just saying it's an inelegant approach. Noted. Please be aware however that bugs are for asking for changes, not for complaining about lack of elegance — I recommend using one's blog for the latter. > > If you mean that HTML should support namespace declarations, then I don't think > > it's crazy, but I don't think it's a good idea, either. It's not clear how it > > would work in a backwards-compatible manner. It would also mean dragging the > > whole rebindable-prefix mess into text/html, which I really think would do the > > Web authoring community a big disservice. > > Eventually you're going to have to face this in some way, in one of these bugs, > in some issue. It will not go away. Let's deal with it here. What do you propose we change?
This bug predates the HTML Working Group Decision Policy. If you are satisfied with the resolution of this bug, 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 This bug is now being moved to VERIFIED. Please respond within two weeks. If this bug is not closed, reopened or escalated within two weeks, it may be marked as NoReply and will no longer be considered a pending comment.