- From: Jon Barnett <jonbarnett@gmail.com>
- Date: Sun, 8 Jul 2007 20:54:15 -0500
- To: "Thomas Broyer" <t.broyer@gmail.com>
- Cc: public-html@w3.org
- Message-ID: <bde87dd20707081854g5489f421ve2ef5bc2be5a8031@mail.gmail.com>
On 7/8/07, Thomas Broyer <t.broyer@gmail.com> wrote: > > If you have <table><tr><td>cell</td></tr></table> in an XHTML document > (XHTML 1.0 or 1.1, or the XML serialization of HTML 5), the DOM won't > contain a <tbody> but <tr> will actually be a direct-child element of > <table>, so any CSS selector using tbody won't match. > If you insert the same snippet in an HTML document, a <tbody> will be > inserted, because that's how the relationship between the > serialization and the infoset/DOM is defined (there's always a <tbody> > and in some cases its start and end tags can be omitted, so it doesn't > appear at all in the serialization); so the CSS selector "table > tr" > won't ever match any <tr> element. > The XHTML 1.0 Strict DTD allows both <col> and <tr> to be children of <table> The HTML 4.01 Strict DTD allows <col> but not <tr> to be children of <table> The HTML5 draft allows <tr> but not <col> to be children of <table> I added a <col> element to my testcase, and Internet Explorer6|7 is the only (!) browser that automatically puts a <colgroup> element in the DOM the way HTML 5 says. Firefox, Opera, Safari do not generate the <colgroup> element. I don't know if IE's behavior alone is justification for the current draft. HTML 5 currently saying the opposite of HTML 4 with respect to <col> and <tr> is curious to me. I don't know the answer to these questions: 1) How important is it for current valid HTML 4 and XHTML 1 documents to be valid HTML 5 documents. Obviously some elements and attributes are dropped, but content model changes like this are rare. 2) How important is it that XHTML 5 documents be serializable as valid HTML 5 documents 3) How important is it that XHTML 5 and HTML 5 be parsable and reserliazable (as I described earlier) without changing the DOM. These are questions I'd like to see answered in general. I may be completely overplaying the importance of converting XHTML to HTML and vice versa. Scott Lewis wrote: > Some UAs do even today. In quick testing, serving an XHTML1 Strict > document[1] with an application/xhtml+xml doctype resulted in: > - Safari 3 beta inserting the <tbody> > - Opera 9.21 not inserting the <tbody> > - Firefox 2.0.0.4 and 1.5.0.9 refusing to render the document > - IE 7.0.5730.11 rendering the document as if the <tbody> were > inserted (I didn't check the DOM for it's presence) > Did you see my test documents and my messages above? [1] When parsed as HTML and rendered in standards-compliance mode, ALL browsers insert the <tbody> element. When parsed as XML in standards compliance mode, no browsers insert the <tbody> element (this is expected), except IE which can't properly handle XHTML. This is not "wildly inconsistent". http://lists.w3.org/Archives/Public/public-html/2007Jul/0472.html -- Jon Barnett
Received on Monday, 9 July 2007 01:54:30 UTC