Re: handling fallback content for still images

On Jul 5, 2007, at 14:15, Robert Burns wrote:

> On Jul 5, 2007, at 5:48 AM, Henri Sivonen wrote:
>
>> If there's an existing facility for doing foo and authors don't  
>> use it, anyone who suggests adding a new facility for doing foo  
>> should present an extremely strong case why the difference between  
>> the old way of doing foo and the proposed new way of doing foo is  
>> the key to getting authors to do foo.
>
> First of all, your resistance here isn't to a new facility. Its to  
> <img></img> in xml. Its a facility that's already that and Opera  
> and Mozilla already treat it the way they should.

<img>content</img> in XHTML is not an existing fallback facility. It  
is an existing undocumented facility for hiding part of the DOM from  
the presentation layer under all conditions--even when presentation  
of the fallback is called for.

> Are you seriously suggesting that we should tell authors its bad  
> practice to deliver content targeted at those browsers as xml and  
> with fallback in their <img> elements? That's absurd.

I indeed am seriously suggesting it. If you put the "fallback" in the  
element content, people who'd actually need the fallback content and  
are using shipped Firefox or Opera are deprived of the fallback content.

> As anyone who's followed the recent history of the web knows, there  
> are all sorts of reasons fallback content for <img> has not worked.

You mean alt hasn't worked? Why do you believe your alternative would  
"work" for whatever threshold of "working" you are applying to alt?

> Just comparing it to fallback content for <object>, we can see that  
> it doesn't work because @alt and @longdesc make it plain-text or  
> cumbersome to implement and poorly supported respectively.

alt makes fallback plain text, yes.

> Authors provide fallback to <objectt> because its easy to do  
> effectively and supports rich media and semantically rich fallback.

Have you surveyed the actual Web and found that authors generally  
provide "rich" fallback for <object>?

>>> However, it should be a goal of ours to provide a language that  
>>> services the needs of authors.
>>
>> If evidence suggests that authors (en masse, not just a few  
>> outliers) don't use a given facility in an analogous situation,  
>> chances are that expanding the facility to another situation isn't  
>> actually servicing the real needs of authors.
>
> There is no analogous situation.

There is presenting visual embedded content (not necessary stills)  
using <object>. Also, there's the case when people *do* provide  
longdesc (to see if they make it "rich" when they *do* provide  
*something*).

> We don't have an <img> element in text/html that supports rich  
> fallback. We never did. I challenge you to find a place where we do.

That's a bogus challenge.

You are asking other people to incur the non-trivial cost of the  
change you are proposing. What you are proposing would have been nice  
15 years ago from a clean slate. No doubt about that. However, now is  
not 15 years ago and there is already a solution that covers the  
simpler non-"rich" case. You are not proposing from going from no  
fallback to rich fallback. You are proposing going from the  
possibility of having non-rich fallback to the possibility of having  
non-rich fallback and rich fallback.

Therefore, you are the one who is challenged to make the case that
  1) The incremental possibility of having rich fallback would be  
used by authors (in non-negligible quantity) if it were available.
  2) That the additional usefulness of the "rich" increment would be  
so great when it would actually be used that it would justify the  
cost you are asking others to incur.

When making the case, you can't *know* the possible "what if future"  
but extrapolation from existing content pointed at by longdesc (when  
it is used in the first place) and existing usage of <object> fall  
back would be good places to start guessing from.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Thursday, 5 July 2007 13:03:10 UTC