Re: handling fallback content for still images

On Jul 9, 2007, at 3:40 AM, Robert Burns wrote:

>
> On Jul 9, 2007, at 5:33 AM, Maciej Stachowiak wrote:
>>
>> I'm not sure any more what you mean by current behavior. To my  
>> knowledge:
>
> That surprises me. I wouldn't have guessed Safari was inserting a  
> tbody in the DOM for XHTML. I saw that it was, in beta 3, but I  
> guess I though that was a beta issue. So this means you were  
> treating XHTML (when consumed as XML) just the same as you would  
> treat HTML. But now you're moving away from that (or you will be).

For this one issue in isolation, yes. But it's more accurate to think  
of this one quirk as a bug than as HTML-like behavior.

>> - Safari 2 inserted a tbody element into the DOM for XHTML. This  
>> has been true in Safari for a while. I think it is still true in  
>> the Safari 3 beta.
>> - In current SVN WebKit, we no longer insert a tbody element into  
>> the DOM in xhtml, but we do have the relevant anonymous boxes in  
>> the render tree. Someday this will likely be picked up in a  
>> released Safari version.
>>
>> This affects at least the following things:
>>
>> 1) Styling the tbody element.
>> 2) CSS selectors that assume tbody is or isn't present but target  
>> tr or td, etc.
>> 3) DOM traversals that look for tr elements expecting the tbody to  
>> be there, or to not be there.
>> 4) Table-specific DOM methods like HTMLTableElement.insertRow,  
>> which could have different behavior depending on whether that  
>> implicit tbody is in the DOM.
>> 5) innerHTML on the table will give different results, when  
>> supported for XHTML.
>>
>> I'm sure there's more I am not thinking of. So a construct like  
>> <table><tr><td>foo</td></tr></table> could have all sorts of  
>> behavior differences in HTML vs. XHTML, depending on what scripts  
>> and stylesheets you are using.
>
> We expected that (in this thread). But you're saying that until the  
> next release of Safari, it is not treated differently. Am I  
> understanding you correctly?

For this one case, yes, but I believe this is the only such HTML quirk  
that we mistakenly had in our XML parser. We don't implicitly create  
html, head or body elements in XHTML for instance. We also won't close  
a table if you hit a stray <table> tag inside it that is not in a  
cell. We don't implicitly close <li> or <p> elements when hitting  
another open tag of the same type. And so forth.

>> (Note, the tbody isn't only in the DOM in HTML when you say  
>> <table><tr>; it has an implicit open tag which means that  
>> semantically it is always there in the document, even when there  
>> isn't a tag for it. Yes, this is weird and confusing. But we are  
>> stuck with it.)
>
> No, we understand that. That's been much of the thrust of this  
> discussion: i.e., how UAs and authors should be guided on these  
> differences by the HTML5 draft (if at all).

I'd say that authors should probably avoid serving documents as  
different doctypes to different UAs. HTML5 makes it easier to do so  
and have a conforming document,

Received on Monday, 9 July 2007 10:54:01 UTC