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

I think you have some errors in your test. Firefox 2.0.0.4 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,
Rob

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