[Bug 7510] Allow elements beyond just HTML, MathML, and SVG into SVG element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7510


Shelley Powers <shelleyp@burningbird.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #8 from Shelley Powers <shelleyp@burningbird.net>  2009-09-22 13:11:16 ---
(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. 



. 


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 22 September 2009 13:11:27 UTC