- From: Robert Burns <rob@robburns.com>
- Date: Mon, 9 Jul 2007 02:15:28 -0500
- To: Henri Sivonen <hsivonen@iki.fi>
- Cc: Jon Barnett <jonbarnett@gmail.com>, "Thomas Broyer" <t.broyer@gmail.com>, public-html@w3.org
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? On Jul 9, 2007, at 2:01 AM, Henri Sivonen wrote: > > On Jul 9, 2007, at 04:54, Jon Barnett wrote: > >> The HTML5 draft allows <tr> but not <col> to be children of <table> > > However, the HTML5 parser will never produce a DOM that has a <tr> > as a child of <table>. To get a DOM like that, you need to use > scripting or the XML serialization. So there won't be an HTML5 parser that's capable of parsing the xml serialization. Is that right? 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). > 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? Upon de-serialization, the DOM will have a tbody though. Or do we want something different? Take care, Rob
Received on Monday, 9 July 2007 07:15:37 UTC