Re: handling fallback content for still images

On Jul 5, 2007, at 5:48 AM, Henri Sivonen wrote:

> If there's an existing facility for doing foo and authors don't use  
> it, anyone who suggests adding a new facility for doing foo should  
> present an extremely strong case why the difference between the old  
> way of doing foo and the proposed new way of doing foo is the key  
> to getting authors to do foo.

First of all, your resistance here isn't to a new facility. Its to  
<img></img> in xml. Its a facility that's already that and Opera and  
Mozilla already treat it the way they should. Are you seriously  
suggesting that we should tell authors its bad practice to deliver  
content targeted at those browsers as xml and with fallback in their  
<img> elements? That's absurd.

As anyone who's followed the recent history of the web knows, there  
are all sorts of reasons fallback content for <img> has not worked.  
Just comparing it to fallback content for <object>, we can see that  
it doesn't work because @alt and @longdesc make it plain-text or  
cumbersome to implement and poorly supported respectively. Authors  
provide fallback to <objectt> because its easy to do effectively and  
supports rich media and semantically rich fallback.

>
>> However, it should be a goal of ours to provide a language that  
>> services the needs of authors.
>
> If evidence suggests that authors (en masse, not just a few  
> outliers) don't use a given facility in an analogous situation,  
> chances are that expanding the facility to another situation isn't  
> actually servicing the real needs of authors.

There is no analogous situation. We don't have an <img> element in  
text/html that supports rich fallback. We never did. I challenge you  
to find a place where we do. The resistance to this becomes more and  
more bizarre with every email message I read.

Take care,
Rob

Received on Thursday, 5 July 2007 11:17:12 UTC