Re: handling fallback content for still images

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

> On Thu, 05 Jul 2007 11:44:58 +0200, Robert Burns <rob@robburns.com>  
> wrote:
>> 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.
>
> You put it down for "pro".

I did?

"Cons:

forks fallback solution for different serializations"

How is that putting it down for pro.

> Saying that authors are already familiar with <img>. I'm saying  
> they'll just be confused given the amount of XHTML treated as text/ 
> html already and authors complaining in bug databases about <span / 
> > or <textarea /> not working as described by XML...

Yes, I understand that's why I added the con. Should I add it a  
second time? I've said this again and again this will take a long- 
term solution approach. In that time-frame authors may not even know  
what a text/html compatible serialization is? They won't be confused  
because there might come a time when no one uses that serialization  
anymore.

>>> 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.
>
> The wiki page should explain it.

I thought it did. You're welcome to edit the wiki page. Right now I  
think all of the pages are a bit of a mess, but I'm sure we'll get  
them in order over the next few weeks.

>
>
>> 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.
>
> Is there any evidence that suggests that authors will start  
> providing more meaningfull fallback when they can have more than  
> just text? For instance, what do authors currently do for <object>  
> when they use it for Flash or video or some such?

I'm not a palm reader. I don't know the future. Is there any evidence  
that the world wide web will exist next year? I know I couldn't prove  
it will. However, it should be a goal of ours to provide a language  
that services the needs of authors. Why are you so resistant to  
providing these facilities? I guess if you could say a little  
something about that, I could respond and we would have a dialog. At  
this point I can't even imagine what could motivate your resistance.

>> [...] And as many have said before, this is certainly more of a  
>> problem to solve than the problems that inspired <video> and <audio>.
>
> Saying it many times does not make it true.

No. I wasn't trying to make it true. That its true I think is  
obvious. I was simply trying to reiterate so you wouldn't forget  
about it.

Take care,
Rob

Received on Thursday, 5 July 2007 10:10:51 UTC