Re: handling fallback content for still images

On 7/8/07, Thomas Broyer <> 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

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

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 and 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".
Jon Barnett

Received on Monday, 9 July 2007 01:54:30 UTC