- From: Thomas Broyer <t.broyer@gmail.com>
- Date: Mon, 9 Jul 2007 09:35:25 +0200
- To: public-html@w3.org
2007/7/9, Robert Burns: > > > I sense that some of the confusion (mine and others) in this thread > may be over what an HTML5 parser is. As we're defining HTML5 to > accept two different serializations, I thought an HTML5 parser would > be an parser capable of parsing HTML5 whether it was from the xml > serialization and delivered as application/xml, text/xml, application/ > xhtml+xml (and several other MIME types) or the classic serialization > and delivered as text/html. However, this comment seems to indicate > that an HTML5 parser only parses the classic serialization. Is that > how you understand it? Yes. "When a document is transmitted with an XML MIME type, such as application/xhtml+xml, then it is processed by an XML processor by Web browsers, and treated as an "XHTML5" document." — http://www.whatwg.org/specs/web-apps/current-work/#html-vs > So there won't be an HTML5 parser that's capable of parsing the xml > serialization. Is that right? Right. But XML-like constructs have been inserted in the HTML serialization (e.g. you're allowed to use a "trailing solidus" in "void elements", just as if you were serializing an empty element with the minimized XML syntax, e.g. <meta name="foo" content="bar" /> ) > Even if that is correct, I think it just moves our problem to other than > the parser (which I'm not sure anyone was even saying it had to be > about the parser). We will still have HTML5 UAs that will build a tree > with a <tr> as a child of a <table>. We still may need to deal with > conversions between HTML5 serializations. > > Even, if we go this Safari/Opera route and recommend an anonymous > tbody element for CSS purposes, there will still be a difference for > DOM purposes. That is we still need to think about how we move > between and among HTML5 xml, HTML5 texts/html and HTML5 DOM (relating > to tbody, col / colgroup, body and head). I don't understand what you're talking about. I suspect your tests are wrong due to the "IE XSLT hack", which has an <xsl:output method="html">, and is applied by some browsers. IMO, if you want IE to display XHTML, you'd better serve it as application/xml and use a complete CSS stylesheet (containing –at least– "head { display: none } p { display: block }" for instance) > > The part of the spec that defines elements generally gives the > > content model that is permissible with the XML serialization and > > doesn't tell you that parts of the content models are impossible in > > the text/html serialization. > > Well if someone: > 1) begins to build a table in the DOM and builds one without an > explicit tbody, > 2) then serializes to text/html > 3) then the table will have no tbody in the text/html serialization, > right? You can't speak that way. Yes, there won't be any <tbody> or </tbody> in the character stream. But as soon as you parse the document (which is what tells you what's really in there), then yes: > Upon de-serialization, the DOM will have a tbody though. > Or do we want something different? I don't think so. It's been like this for ages now: in HTML 4.01, tables don't have tr has children without a tbody (or thead or tfoot) in between, while in XHTML 1.0 you can have a tr as a direct child of a table, without any tbody at all. -- Thomas Broyer
Received on Monday, 9 July 2007 07:35:31 UTC