Re: handling fallback content for still images

On Jul 5, 2007, at 4:36 AM, Anne van Kesteren wrote:

> On Thu, 05 Jul 2007 11:29:23 +0200, Robert Burns <rob@robburns.com>  
> wrote:
>> I added the <img>fallback</img> for xml serialization solution to  
>> the Longdescription page. If anyone can think of any other pros  
>> and cons, please add them.
>>
>> <http://esw.w3.org/topic/HTML/LongdescRetention#preview>
>
> It creates more divergence between the HTML and XHTML  
> serialization. Authors are already confused by subtle API and CSS  
> differences. Making drastic changes like this is not likely to be  
> appreciated. There also seems to be very little benefit given that  
> the HTML serialization is used most often. If anything, we should  
> optimize for that serialization.

I meant to add them to the wiki. I already put that con on the wiki.  
If you'd like to reword it you're welcome to do so.

> I have a very hard time understanding what problem you're trying to  
> solve by the way. There is a requirement listed at the top of the  
> page, but to me that seems addressed by <img alt>.

I think you've asked this several times and I've answered it several  
times, but I'm happy to answer it again. Because <Img> has to be  
empty, authors cannot provide semantically rich or media rich  
fallback content for images in a simple and straight-forward manner  
(as they can for <object>, <video>, <audio>, <iframe>, <object>, and  
<canvas>). <img alt> cannot do that at all. It's really only listed  
there as a token solution. Using, <img longdesc> authors can do that,  
but its very difficult to use and UAs have had trouble understanding  
how to implement it. Other solutions are on the page and each I think  
is better than @longdesc and @alt, though they all have problems  
(especially in the short-term). And as many have said before, this is  
certainly more of a problem to solve than the problems that inspired  
<video> and <audio>.

Take care,
Rob

Received on Thursday, 5 July 2007 09:45:16 UTC