W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: handling fallback content for still images

From: Jon Barnett <jonbarnett@gmail.com>
Date: Sun, 8 Jul 2007 20:54:15 -0500
Message-ID: <bde87dd20707081854g5489f421ve2ef5bc2be5a8031@mail.gmail.com>
To: "Thomas Broyer" <t.broyer@gmail.com>
Cc: public-html@w3.org
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:46 UTC