Re: handling fallback content for still images

I sense that some of the confusion (mine and others)  in this thread  
may be over what an HTML5 parser is. As we're defining HTML5 to  
accept two different serializations, I thought an HTML5 parser would  
be an parser capable of parsing HTML5 whether it was from the xml  
serialization and delivered as application/xml, text/xml, application/ 
xhtml+xml (and several other MIME types) or the classic serialization  
and delivered as text/html.  However, this comment seems to indicate  
that an HTML5 parser only parses the classic serialization. Is that  
how you understand it?

On Jul 9, 2007, at 2:01 AM, Henri Sivonen wrote:

> On Jul 9, 2007, at 04:54, Jon Barnett wrote:
>> The HTML5 draft allows <tr> but not <col> to be children of <table>
> However, the HTML5 parser will never produce a DOM that has a <tr>  
> as a child of <table>. To get a DOM like that, you need to use  
> scripting or the XML serialization.

So there won't be an HTML5 parser that's capable of parsing the xml  
serialization. Is that right? Even if that is correct, I think it  
just moves our problem to other than the parser (which I'm not sure  
anyone was even saying it had to be about the parser). We will still  
have HTML5 UAs that will build a tree with a <tr> as a child of a  
<table>. We still may need to deal with conversions between HTML5  

Even, if we go this Safari/Opera route and recommend an anonymous  
tbody element for CSS purposes, there will still be a difference for  
DOM purposes. That is we still need to think about how we move  
between and among HTML5 xml, HTML5 texts/html and HTML5 DOM (relating  
to tbody, col / colgroup, body and head).

> The part of the spec that defines elements generally gives the  
> content model that is permissible with the XML serialization and  
> doesn't tell you that parts of the content models are impossible in  
> the text/html serialization.

Well if someone:
1)  begins to build a table in the DOM and builds one without an  
explicit tbody,
2) then serializes to text/html
3) then the table will have no tbody in the text/html serialization,  

Upon de-serialization, the DOM will have a tbody though.  Or do we  
want something different?

Take care,

Received on Monday, 9 July 2007 07:15:37 UTC