Re: handling fallback content for still images

On Jul 6, 2007, at 7:34 PM, Jon Barnett wrote:

> On 7/6/07, scott lewis <sfl@scotfl.ca> wrote:
> > I'm not sure if Thomas is confused. There is certainly an issue
> > that our recommendations should deal with. In other words when
> > serializing as XML, should a translating UA include explicit
> > <tbody> elements when serializing to XMl? There may problems with
> > doing so, but there will also be problems with not doing so. For
> > example, a user may wonder why the CSS stopped working simply from
> > saving to a different serialization.
>
> 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.)
>
> scott.
>
> I created two test pages:
> http://websandbox.net/media/examples/tbody.html
> http://websandbox.net/media/examples/tbody.xml
>
> [..]
>
> Therefore, I propose that the content model section here be changed:
> http://www.whatwg.org/specs/web-apps/current-work/#table
> from "followed by either zero or more tbody elements or one or more  
> tr elements..."
> to "followed by either zero or more tbody elements..."
>
> That would make it non-conforming for a <tr> element to be a child  
> of <table> in XHTML (it would be automatically inserted in HTML  
> syntax.
>
> (The same issue would apply to <col>, and the specification already  
> disallows <col> as a child of table in the same manner I'm proposing)
>
> Making <table><tr>... non-conforming in XHTML would not break  
> existing web pages - just their validation.

Yes, that is another way to deal with it. I don't like that way in  
particular because it places the burden on xml serialization authors.  
In other words the reason we allow certain elements to be omitted in  
xml is so that authors who don't need to get a handle on those  
elements (either through the DOM or through CSS), don't need to  
bother with them. Its for that reason that I don't like how the draft  
handles <col>. That's a very good example of what I'm talking about.  
Imagine a table that includes hundreds of columns and the author  
feels no ned to group those columns. For the xml serialization the  
current draft would require <table><caption>a caption</ 
caption><colgroup><col/> </colgroup> <colgroup><col/> </ 
colgroup>....<colgroup><col/></colgroup><tbody>...</tbody></table>.

Where the colgroup <colgroup><col/> </colgroup> would be repeated  
hundreds of times.l Yet the colgroup would add nothing to the  
expressibility for the author.

I think its better to let the xml serialization alone and explicitly  
describe how conversions/translations should occur. For example, from  
html to xml, we could require UAs add the implicit tbody. In going  
from xml to html, the UA doesn't add the implicit tbody. This  
requires UA awareness of the serialization it started with. I'm not  
sure if this creates any implementation difficulties. Any thoughts?  
Things supported in the DOM, but not supported in any serialization  
should probably just not be allowed in the first place.

Take care,
Rob