Re: handling fallback content for still images

On Jul 5, 2007, at 9:27 AM, James Graham wrote:

>
> Robert Burns wrote:
>> On Jul 5, 2007, at 6:39 AM, Anne van Kesteren wrote:
>>>>>
>>>>> Ok, I hope I explained well enough why I think this is not  
>>>>> obvious at all.
>>>>
>>>> No. That had nothing to do with <video> and <audio>. Look I have  
>>>> nothing against those additions to the language. But I can't  
>>>> even begin to come up with a use-case for <video> and <audio>  
>>>> that could come close in importance to the need to provide  
>>>> fallback for still images. And no one else has been able to  
>>>> describe any pressing need for those either.
>>>
>>> James explained the reasons for <video> and <audio> in a separate  
>>> thread.
>> Yes he explained that video and audio need to be first class  
>> citizens with fully featured fallback content. And you seem to be  
>> saying that still images do not deserve to be first class citizens  
>> in HTML with fully featured fallback content.
>
> Images clearly are first class citizens in HTML. That they don't  
> support rich fallback doesn't change that.
>
> If you believe it is necessary to introduce a new method of marking  
> up images that does allow for rich fallback you need to demonstrate  
> that the benefits outweigh the costs. In particular, you need to  
> demonstrate:
>
> a) That there is a real use case that demands rich fallback for  
> images. Possibly anyone with this use case today would be using  
> longdesc to provide the rich content so demonstrating the correct  
> use of longdesc with rich contents would be helpful. Alternatively  
> a series of examples in which the user experience is significantly  
> degraded where rich fallback is not available are likely to be  
> persuasive.

Why would correct use of the longdesc help my case. My point is that  
longdesc is to complicated for authors to use. <object> as it stands  
now is also too complicated for authors to use (and I've already  
suggested we try to use our draft recommendation to eventually  
address that issue too).

> b) That there is a viable migration path from here to there. For  
> example, people are trying to find migration paths based on  
> <picture> elements + conditional comments. They all look pretty  
> painful to me. If there is no sensible migration path for authors  
> that can deal with a mixture of supporting and non-supporting UAs  
> the element will never be used so there's no point in speccing it.

I do not think those migration paths look very painful. Regardless,  
if we're serious about interoperability,, we need to address the  
issue of canonical empty elements in text/html that are no longer  
necessarily canonically empty in xml (in other words we can say  
they're empty, but if we want to facilitate authoring errors, then we  
need to accommodate the possibility that authors will place content  
within the start and end of an image element; what might they mean if  
they do that).

I would like to  do as you suggest. I will start immediately. Could  
you point me to the document for the <video>, <audio> and <canvas>  
elements that does the same tasks. I think it will serve as an  
excellent template for my work. With the use of that as a template,  
my task will be far easier than the task for making the case for why  
our final recommendation will include <video>, and <audio>.


> It is clear that there is a certian amount of scepticism about the  
> need or viability of what you are proposing. The correct response  
> to that is not to give up in frustration as Phillip apparently did;  
> rather it is to provide evidence for your position. Often (and by  
> no means just in HTML discussions) it turns out that actual  
> evidence undermines all the well-constructed theoretical arguments  
> that preceded it.

No, it is not clear that these is skepticism about what I am  
proposing. There is quite a bit of support for what I am proposing  
(providing parallel rich fallback content for still images). There is  
also a few who are responding with quite a bit of irrational  
resistance to what I am proposing: particularly in this latest  
suggestion, where I'm not actually proposing we change anything  
fundamental, but instead provide interoperability and author guidance  
for something that is already happening (non-inter-operably) in UAs.

Take care,
Rob

Received on Thursday, 5 July 2007 14:51:58 UTC