Re: handling fallback content for still images

On Jul 9, 2007, at 11:31, Robert Burns wrote:

> On Jul 9, 2007, at 3:12 AM, Henri Sivonen wrote:
>
>> On Jul 9, 2007, at 10:52, Robert Burns wrote:
>>
>>> Yes, I understand. The point here was that Henri said that tr  
>>> cannot be a child of table in the text/html serialization.  
>>> However, it can.
>>
>> No, it can only look like it to the author who doesn't know how  
>> HTML works on this point.
>
> There's a bit of word play going on here that I don't think is at  
> all helpful.

The point is that in text/html, there will be a tbody element even if  
there aren't any <tbody> tags. This *is* confusing, but the confusion  
is not of our making. We can't remove the confusion retroactively.  
Removing it going forward would break backwards compat in some way.

> When authoring a document, the author want to know what element can  
> I put inside of this table element. Oh, it says here I can put a tr  
> inside here. Great.

The part of the spec that gives the content models of elements really  
needs to get some warnings for readers who read the spec piecemeal. I  
am not in any way defending the situation that the spec doesn't warn  
you about this in that part of the spec.

> Telling the author that they don't know how HTML works is just  
> plain silly.

Well, if you don't know that an HTML parser infers tbody even when  
the tags aren't there, you don't know how it works. It is unfortunate  
that there are gotchas like this, but we didn't put them there and  
we'd break compat by taking them out.

> HTML is not only the DOM. It is many things.

There's no parent-child elements in the source text. There are tags.  
When you start talking about parent-child, you should be talking  
about the document tree or you are confusing things further.

> When talking about authoring, the serialization is very important.

Yes.

> The fact that the DOM will later infer a tbody in there is an  
> interesting detail for an author to know.

The *parser* infers it.

> However, its not the "real" way HTML works.

The way it works in the most common implementations seems pretty real  
to me.

> <with-the-Henri-attitude> Perhaps I should point you to some  
> serialized HTML so that you can see how HTML really works.</with- 
> the-Henri-attitude> :-)

Yes, there are a lot of serialized HTML without <tbody> tags.

> <rant>The thing that frustrates me here. Is that we in the WG  
> already know this stuff.

Based on the messages seen recently, no, as a collective, we don't  
apparently. :-(

> Yet you treat it like there's this magical secret that will soon be  
> revealed to us.

I'm most certainly not treating it as a secret. I encourage everyone  
to read the spec draft (which is not a secret) to find out stuff.

> Even with the discussion about the parser, we weren't talking about  
> the parse.

That makes no sense.

> We were ()and are) talking about an HTML5 UA (including multiple  
> parsers) and how it handles conversions between serializations.

Typical UAs don't convert between the serializations. What makes you  
think that they do?

> But then you shifted the conversation to be about the parser so  
> that you could say: "see the parser doesn't handle XML  
> serializations".

You yourself said you were sensing a confusion about the point. Is  
clarifying confusion not "shifting the conversation"?

> Fine, then the conversation wasn't about the parser at all.</rant>

The text/html serialization and the HTML5 parsing algorithm have an  
intimate relationship. It makes no sense to talk about the properties  
of the serialization without understanding how it gets parsed,  
because UAs act on the result of the parse.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 9 July 2007 08:56:27 UTC