Re: handling fallback content for still images

On 8 Jul 2007, at 1523, Thomas Broyer wrote:

> 2007/7/7, scott lewis:
>>
>> On 6 Jul 2007, at 1644, Robert Burns wrote:
>> >
>> > I'm not sure if Thomas is confused.
>
> I wasn't.
>
>> > 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.)
>
> No it won't, in the case of application/xhtml+xml.

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)

In a nutshell, current handling is wildly inconsistent.


> The relationship between XML and the XML Infoset is clearly defined;
> as is the relationship between the XML Infoset and the DOM.
> There's no reason an XML parser would insert an element in a document
> if it's not present in its XML serialization.

There's the problem: we're talking past each other. I'm talking about  
the behaviour of an HTML5 parser, you're discussing XML parsers. :)


> 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.

If one has a strict XML parser that needs to process HTML documents,  
the simplest solution would seem to be to place the equivalent of  
Tidy in front of it to transform the HTML into the particular flavour  
of HTML5/xml the parser wants. Which would have the advantage of  
letting the application consume *any* HTML document, not just  
strictly conforming XHTML1 and HTML5/xml.

Considering the wildly inconsistent current handling I'm not sure  
that the current HTML5/xml serialization could be reasonably defined  
as compatible *or* incompatible.

s.



1:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">
<head>
    <title>Test Page</title>
<style type="text/css">
/*<![CDATA[*/
          body {
             background: blue;
          }
          table > tbody > tr > td {
             background: red;
          }
/*]]>*/
</style>
</head>

<body>
    <table>
       <tr>
          <td>cell</td>
       </tr>
    </table>
</body>
</html>

Received on Monday, 9 July 2007 01:35:45 UTC