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

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





--- Comment #6 from Shelley Powers <shelleyp@burningbird.net>  2009-09-23 02:09:41 ---
> (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.


-- 
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 02:09:51 UTC