Re: handling fallback content for still images

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.

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Received on Thursday, 5 July 2007 15:18:19 UTC