Re: handling fallback content for still images

On Jul 5, 2007, at 10:17 AM, James Graham wrote:

>
> Robert Burns wrote:
>>> 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.
>
> Because it would demonstrate that, despite the complexity, authors  
> had sufficient need for rich fallback that using longdesc to  
> provide it was worthwhile.
>
> If you can't demonstrate that authors are using the existing  
> mechanisms that are in place, you have the somewhat harder task of  
> demonstrating that they would use rich fallback if only it were  
> epsilon easier, where epsilon is the difference in difficulty  
> between the simplest existing mechanism and your proposal.
>
>
>>> 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 agree that we should cover that issue in the spec.
>
>> 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'm not sure what you mean "document" here. I had in mind an email  
> or a wiki page. Therefore I suggest you look for discussions about  
> audio, video and canvas in the WHATWG mailing list archives where  
> the fallback issue was discussed. Note that the situation for these  
> elements is rather different for that which you are proposing since  
> they introduce entirely new features rather than reworking an  
> existing feature.
>
>> 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.
>
> Calling people who disagree with you "irrational" doesn't seem  
> constructive; to me it suggests that you are not taking the time to  
> understand what they are saying.

No, I understand what you're saying and its irrational.

Received on Thursday, 5 July 2007 15:21:09 UTC