Re: handling fallback content for still images (www-archive)

On Jul 5, 2007, at 8:06 AM, Anne van Kesteren wrote:

> Taking it to www-archive as it doesn't feel worth it to discuss  
> this on public-html.
>
>
> On Thu, 05 Jul 2007 14:51:06 +0200, Robert Burns <rob@robburns.com>  
> wrote:
>> Anne, you're definitely talking about forbidding it. Of the three  
>> visual browser engines that handle XHTML at all: Presto and Gecko  
>> both handle the non-fallback state just as we would want with XHTML.
>
> Sure. That's how replaced elements work.
>
>
>> WebKit does not, but that could get fixed.
>
> It doesn't? Weird.
>
>
>> I haven't tested any Aural or Tactile UAs yet, but that's where we  
>> really need this to work and it wouldn't surprise me if it already  
>> works. It is a minor bug if Opera doesn't display the fallback  
>> content when the image is not available.
>
> Minor... right.
>
>
>> [...]
>>
>> However, you're position seems to be that we should forbid this  
>> behavior in UAs. We should go right now and file bugs to Opera and  
>> Mozilla to tell them that they're handling xml parsing and  
>> rendering incorrectly.
>
> No, they're not handling it incorrectly. They're handling it  
> perfectly fine.
>
>
>> They should display the contents of the <img> element just as the  
>> do when rendering text/html.
>
> You seem to misunderstand HTML parsing.
>
>
>> We should forbid authors from taking advantage of this bug in  
>> Opera and Firefox and put them on notice that we're going to make  
>> sure the fallback content doesn't work that way in the future.
>
> I'm not sure what this means.
>
>
>> In contrast, I'm suggesting that we take advantage of this break  
>> in parsing and add UA conformance criteria that specifies  
>> precisely how UAs should handle this fallback. Whatever we  
>> determine for <video>, <audio>, <canvas>, and <object> should also  
>> guide us in our conformance criteria for <img>fallback</img>.  
>> Authors deploying XML will most likely take advantage of this  
>> unless we forbid it. And why shouldn't UAs handl <img> in the same  
>> manner it handles the other embedded content elements and their  
>> fallback.
>
> Because that would be inconsistent with how they handle <img> in  
> the HTML serialization. (There's also alt= to deal with of course,  
> but that's minor.) The other thing is that the advantage is not  
> really there as I don't think we'll get much XHTML adoption.
>
>
>>> Then there is the question of how common markup fallback would  
>>> be. If it is very common it might be worth it to investigate  
>>> something like <picture> / <graphic>. If it is not very common we  
>>> should simply consider having authors use <object> which already  
>>> solves this use case. (If they need it to work in current  
>>> versions of Internet Explorer they can maybe use some type of  
>>> scripted workaround or any of the alternatives proposed elsewhere  
>>> in this thread.)
>>
>> You exhibited the same strong resistance to introducing a new  
>> still image element such as <picture>  that you're now exhibiting  
>> toward <img>fallback</img>. Again, we have a clear use-case. The  
>> current situation is not working.
>
> The current situation is working. Just stating that it doesn't work  
> is not convincing.
>
>
>> Many creative approaches have been put forward that meet the  
>> criteria laid out. In other words it shouldn't break existing  
>> content, it should degrade gracefully, etc. But then you keep  
>> moving the goal posts. Now we're supposed to just revert to @alt  
>> despite several superior solutions. I don't even know what  
>> criteria is being applied now with the newly moved goal posts.
>
> I don't believe I have ever set any goal posts. Maciej mentioned  
> something about it might being worth a try if I remember correctly.  
> I'm not really convinced there is really a use for it. (Other than  
> a few edge cases <object> already caters for.)
>
>
>> The issue of <img> and elements like it are something we should  
>> provide guidance on for the XML serialization. Will it confuse  
>> authors that there are two serializations: yes. Will it frustrate  
>> authors when they see how much easier it would be to deploy XML  
>> serialized content , but they can't because their targeted  
>> browsers don't support it: yes. But these are issues that I think  
>> are beyond the scope of this WG. The best we can do is try to make  
>> sure that UAs are interoperable whether their XML UAs or HTML5 UAs  
>> or both.
>
> So far I haven't seen much activity in the getting user agents more  
> interopable area. Most of it is people requesting a <burger/>  
> element to be included in the next version of HTML. And complaints  
> about some explicit accessibility features from HTML 4 that are not  
> included in the current draft because several use cases were not  
> considered and not much research was done in the area.

I can't imagine how our WG can't be about interoperability. As for  
<burger/> element, the closest thing we have to a <burger/> element  
are the <video>, <audio>, and <canvas> elements.

Take care,
Rob

Received on Thursday, 5 July 2007 15:32:36 UTC