W3C home > Mailing lists > Public > public-html@w3.org > July 2007

Re: handling fallback content for still images

From: James Graham <jg307@cam.ac.uk>
Date: Thu, 05 Jul 2007 15:27:59 +0100
Message-ID: <468CFFEF.4020802@cam.ac.uk>
To: Robert Burns <rob@robburns.com>
CC: Anne van Kesteren <annevk@opera.com>, HTML WG <public-html@w3.org>

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.

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.

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.

-- 
"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 14:28:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:02 GMT