- From: Jon Barnett <jonbarnett@gmail.com>
- Date: Fri, 6 Jul 2007 19:34:16 -0500
- To: "scott lewis" <sfl@scotfl.ca>
- Cc: "Robert Burns" <rob@robburns.com>, "HTML Working Group" <public-html@w3.org>
- Message-ID: <bde87dd20707061734r1be04592na3902ffbce00ce4e@mail.gmail.com>
On 7/6/07, scott lewis <sfl@scotfl.ca> wrote: > > I'm not sure if Thomas is confused. There is certainly an issue > > that our recommendations should deal with. In other words when > > serializing as XML, should a translating UA include explicit > > <tbody> elements when serializing to XMl? There may problems with > > doing so, but there will also be problems with not doing so. For > > example, a user may wonder why the CSS stopped working simply from > > saving to a different serialization. > > How would the CSS break? CSS rules are applied against the DOM and > the <tbody> will always be represented in the DOM. (If the element is > not present in a serialized document it is inserted into the DOM by > the UA.) > > scott. I created two test pages: http://websandbox.net/media/examples/tbody.html http://websandbox.net/media/examples/tbody.xml In Firefox, Opera, and Konqueror, in the HTML document, the <tbody> element is generated as it should be: its start tag is optional, and this affects both the DOM and CSS selectors. In Konqueror, the Javascript fails, but the point is still valid. In the XML document, the <tbody> is not generated. <tr> is a child of <table> - this is expected, since you don't expect the UA to insert things into an XML document. IE7: In both documents, the <tbody> element is generated. Even though I'm using my XSL hack to make IE render the XML document, I suspect that IE's XSL parser transforms the XML into plain HTML text that is then parsed by IE's HTML parser (this explains my last example that used it as well) If my HTML document were parsed, reserialized as XHTML, parsed, and reserialized as HTML, and parsed, the new HTML DOM would be the same as the original HTML DOM. If my XML document were parsed, reserialized as HTML, parsed, and reserialized as XML, and parsed, the new XML DOM would be different from the original XML DOM because a new <tbody> element would be present in the document, and the table > tr > td selector would no longer work (among other issues). This issue doesn't apply to any other elements that have optional start tags in HTML - since <html>, <head>, <body> are required, it would be non-conforming for an XHTML document not to have them to begin with. Therefore, I propose that the content model section here be changed: http://www.whatwg.org/specs/web-apps/current-work/#table from "followed by either zero or more tbody<http://www.whatwg.org/specs/web-apps/current-work/#tbody>elements *or* one or more tr <http://www.whatwg.org/specs/web-apps/current-work/#tr>elements..." to "followed by either zero or more tbody<http://www.whatwg.org/specs/web-apps/current-work/#tbody>elements **..." That would make it non-conforming for a <tr> element to be a child of <table> in XHTML (it would be automatically inserted in HTML syntax. (The same issue would apply to <col>, and the specification already disallows <col> as a child of table in the same manner I'm proposing) Making <table><tr>... non-conforming in XHTML would not break existing web pages - just their validation. -- Jon Barnett
Received on Saturday, 7 July 2007 00:34:22 UTC