Re: handling fallback content for still images

On Jul 5, 2007, at 7:17 AM, Anne van Kesteren wrote:

Not sure if this was supposed to be on-list, but...

>
> On Thu, 05 Jul 2007 14:10:42 +0200, Fabien Basmaison  
> <fabien.basmaison@arkhi.org> wrote:
>> But don't you agree that an alternate representation of the image  
>> can contain hyper links (or even <strong>, or <cite>, ...)?
>> We're still dealing with HyperText, after all; no matter the place  
>> this hyper is placed in.
>
> Indeed.
>
>
>> I agree the context may be very important to the background of an  
>> image, though getting redundant some informations available or not  
>> in the @alt most of the time, but why "forbidding" this possibility?
>
> I don't think we're forbidding anything, we're dealing with  
> constraints. The constraints being that <img> is widely popular and  
> well supported and therefore making it non conforming is not likely  
> to go down well.

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.  
WebKit does not, but that could get fixed. 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. This is something that we should deal with. However, we  
haven't even laid out conformance criteria for how visual UAs should  
handle fallback content, so how could we expect Opera and Mozilla to  
already implement what we haven't even specified.

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. They should display the contents of the <img> element  
just as the do when rendering text/html. 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.

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.

> 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. 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.

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.

Take care,
Rob

Received on Thursday, 5 July 2007 12:51:31 UTC