Re: handling fallback content for still images

On 8 Jul 2007, at 2052, Robert Burns wrote:

> 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:
>>>
>>>> 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:
>> [...]
>>
>> 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.

Indeed, my file had an extension of ".html". A little more testing  
reveals that Firefox will reject a document served as application/ 
xhtml+xml if it's name ends in .html, but will accept it if the  
extension is .xml. FF renders the .xml file without a <tbody>, as you  
say. And, conversely while IE will render the .html, it refuses to  
render the .xml file. Safari and Opera rendered both extensions.


> So wildly inconsistent is overstating it a bit.
> [...]

  - Opera 9
     - .html no <tbody>
     - .xml no <tbody>
  - Firefox 2
     - .html Will not render
     - .xml no <tbody>
  - IE 7
     - .html inserted <tbody>
     - .xml Will not render
- Safari 3
     - .html inserted <tbody>
     - .xml inserted <tbody>

Identical documents, identical mimetypes, different extensions.

I'm not convinced that we can dismiss IE7 since the path of least  
resistance and "cargo cult conformance" (not to mention habit) lead  
to XHTML in .html files, and while those files aren't parsed by a  
strict XML parser, they still render in IE7.


>>> [...]
>>> 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).

As I understand the HTML5 spec, it defines one parser for all  
flavours of HTML (HTML[.9-4], XHTML1, and HTML5) regardless of  
serialization. The idea being that users expect UAs to render a  
document with unclosed <li> elements, even if the filename ends in .xml.

s.

Received on Monday, 9 July 2007 03:54:07 UTC