Re: unifying alternate content across embedded content element types

Robert Burns wrote:
> 
> 
> On Jul 14, 2007, at 11:30 PM, Robert Burns wrote:
>> If these same principles should not be applied to <object> then I
>> could understand that. However, the only reason I can think of (and
>> I'm asking for help here in understanding the objections) is that
>> @longdesc is simply more difficult for authors and users to use
>> (compared to <object> contents). Is it that @longdes either requires a
>> separate round-trip to the server or instead, deployment of CSS or DOM
>> calls to deal with concealing the local document fragment until that
>> fallback is requested by the user agent or the user directly. Is that
>> what everyone feels about this. Then just say so. Then I'll know
>> you're understanding what I'm talking about, and we can stop beating
>> the dead horse as Jon put it.
> 
> I should add one caveat. If the sentiment expressed above is the
> sentiment agreed to by everyone, it suggests to me that we should not be
> deprecating @longdesc on element (not that we are, but the current draft
> omits it). If anything, we could stand to lose @alt on <img> before we
> could use the more flexible and richer @longdesc attribute. I'm not
> saying we should get rid of either one, but we should definitely not get
> rid of @longdesc. If @alt is therefore redundant (as others suggest it
> is on <object>), we could consider deprecating that.

I don't think such a suggestion is a useful one to make, because alt=""
will *never* be redundant when the alternative is using another HTML
page to provide fallback content, simply because the latter is a chore
and won't be done by the vast majority of authors.  (longdesc="" didn't
even show up in the top 20 <img> attributes on the Google webstats
survey [1], meaning that it appears on >1% of pages.)

[1] http://code.google.com/webstats/2005-12/element-img.html

Andrew Sidwell

Received on Sunday, 15 July 2007 11:31:55 UTC