- From: Robert Burns <rob@robburns.com>
- Date: Mon, 9 Jul 2007 02:52:10 -0500
- To: Thomas Broyer <t.broyer@gmail.com>
- Cc: public-html@w3.org
On Jul 9, 2007, at 2:35 AM, Thomas Broyer wrote: > 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. Earlier in this thread Mcaiej indicated that Opera and Safari (now anyway with an XML de-serialization) are adding an anonymous tbody element for CSS purposes. This thread has evolved into basically discussing how to deal with subtle differences in the three forms of HTML5: DOM, XML and text/html. I think wit the CSS handled the way Opera and Safari are heading (with XML de-serialization) that takes care of many of the concerns I had. However, there still may be a need to address some subtleties in those particular elements. > 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) No, we're not discussing those tests anymore. These are new tests that are pure XML. The IE tests were incorrect, because IE wasn't consuming them as XML at all. We straightened that out already. >>> 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: Yes, I understand. The point here was that Henri said that tr cannot be a child of table in the text/html serialization. However, it can. From an author's perspective, they want to know if they can start a table element and then insert a table row like: <table><tr>...</tr></table> And they can. This same fragment of text could could be authored for either text/html or xml. Depending on how its delivered to the HTML5 UA, there will or will not be a tbody element in the DOM. That's where this thread has evolved. We're simply discussing how to deal with those subtle differences. >> 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. Yes, I know its been like that. However, the XML anonymous tbody element is a new approach that I think will help wither interoperability tremendously. The question being posed if there's anything the draft should say about things like that (or anything else) for author or UA guidance on conversions between serializations and DOM and treatment of especially XML de-serialized DOMs. Take care, Rob
Received on Monday, 9 July 2007 07:52:21 UTC