[Bug 7703] HTML document conformance should explicitly depend on foreign content conformance

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





--- Comment #3 from Jeff Schiller <codedread@gmail.com>  2009-09-23 00:12:50 ---
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?


-- 
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 Wednesday, 23 September 2009 00:12:59 UTC