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

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.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Thursday, 5 July 2007 13:08:28 UTC