- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 23 Sep 2009 00:41:09 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7703
--- Comment #4 from Cameron McCormack <cam@mcc.id.au> 2009-09-23 00:41:09 ---
(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.
--
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:41:18 UTC