Re: handling fallback content for still images

On Jul 8, 2007, at 8:35 PM, scott lewis wrote:

> On 8 Jul 2007, at 1523, Thomas Broyer wrote:
>> 2007/7/7, scott lewis:
>>>>  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 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)
> In a nutshell, current handling is wildly inconsistent.

I think you have some errors in your test. Firefox on Mac OS  
X rendered the document for me just fine. IE should only render the  
DOM tree for this document It doesn't have the CSs capabilities to  
treat tree of elements as a table (and of course no XHTML handling).  
To my surprise, II also found Safari 3 to be inserting the tbody. My  
guess is that WebKit for Safari 2 would not do this with XHTML.

So wildly inconsistent is overstating it a bit.

 Safari 3 beta is inserting a tobdy
 The others are not
 (IE can't handle XHTML at all and its CSS handling is not capable  
of handling arbitrary XML elements as a table)

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

Are you suggesting that an HTML5 XML parser behave differently than a  
standard XML parser? For example, we could follow the WebKit example  
and recommend HTML5 processors inser tbody for either serialization?  
This could also be applied to colgroup/col and body and head as well.  
I could imagine this being something controversial, but it has some  
merit. I don't think this is in the  current draft however. You would  
be proposing this for the first time here (as far as I can tell).

BTW, I feel like we should expect the same for XHTML processing of  
named character references. In other words inserting &delta; into an  
XHTML document should not lead to a fatal error (as it has sometimes  
been interpreted by UA implementations).

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

This Safari beta handling is fairly new. Without that change (and it  
is still a beta only a few weeks old) there are no inconsistencies.

There is an issue that needs to be dealt with here, and I don't think  
it's already handled adequately in the  current draft. How should  
HTML5 processors handle implied elements when deserialziaing HTML5/ 
XML? Related to that is the question of how conversion UAs should  
perform conversions, in either direction, between HTML5 classic  
serialization and the HTML5 xml serialization

Take care,

Received on Monday, 9 July 2007 02:52:58 UTC