W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > September 2009

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

From: <bugzilla@wiggum.w3.org>
Date: Tue, 29 Sep 2009 09:15:41 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1MsYo9-0001zg-FO@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7703


Ian 'Hixie' Hickson <ian@hixie.ch> changed:

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




--- Comment #7 from Ian 'Hixie' Hickson <ian@hixie.ch>  2009-09-29 09:15:40 ---
> > > 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?


-- 
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, 29 September 2009 09:15:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:01 UTC