Re: handling fallback content for still images

On Jul 8, 2007, at 10:54 PM, scott lewis wrote:

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

How are you changing the MIME type? I was just doing this on my local  
filesystem so changing the filename extension also changes the MIME  
type handling. Are you serving this from an HTTP server? ... then  
setting the MIME Type on just that particular file? Mostly just curious.

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

I'm not dismissing IE7 generally. I'm saying there's no way we can  
test how it handles XHTML handling since it will s imply refuse to  
process that MIME type.

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

I don't think this WG has that much power. HTML5 with XML-like syntax  
and delivered as text/html is one thing. HTML5 serialized as XML and  
processed as XML (i.e., "application/xml", application/xhtml+xml",  
etc.)  requires processors to apply their XML processing (including  
parsing) to that document. Are you suggesting a third sem-XML  
processing? I'm not sure how that would differ from HTML5 text/html  
with simply an XML-like syntax (but even then things like <img></img>  
and <br></br> would not be permitted as it would in a a pure XML  
handling).

My understanding is that we will produce an XML serialization that  
works in a pure-xml processing environment.

Take care,
Rob

Received on Monday, 9 July 2007 04:08:34 UTC