Re: unifying alternate content across embedded content element types

On Jul 15, 2007, at 12:39 PM, Smylers wrote:

> Robert Burns writes:
>> the usage of the two attributes has diverged. The guidance authors  
>> are
>> given for those two attributes has become: 1) @alt for brief
>> equivalent; and 2) @longdesc for more elaborate equivalent.
> Yes.  But more out of necessity and pragmatism (because of the
> historical reasons for how they came about) than because there is  
> an _a
> priori_ reason to make such a distinction:

For whatever historical reasons we have discovered an a_priori reason  
to make such a distinction. The recommendation is to use @alt for  
brief alternate and @longdesc for long alternates. The recommendation  
is also to always use @alt even if one uses @longdesc: in other word  
they are not substitutes. If there was no a priori reason to make the  
distinction I would expect them to be substitutes.

> * People can't use alt for 'rich' alternative content because an
>   attribute simply doesn't allow that.


> * It's much more hassle to use longdesc than to use alt (either  
> creating
>   a separate file and ensuring it never gets separated from the  
> current
>   document, or putting the content elsewhere in the current file and
>   using some CSS to hide it (and not caring about those without CSS)).
>   There's no advantage in doing that in situations where alt suffices.

As I've suggested before, we could add a <longdesc> element for use  
on the same page. It would degrade gracefully in that there's little  
harm done in the description being available to others (in the event  
CSS was missing). It would also allow @longdesc to be even more  
flexible than <object>contents</object>.

> Note that this isn't a useful division in terms of what the author is
> trying to convey.  It isn't that somebody in advance decided to put  
> this
> distinction into HTML.

It is a useful distinction in how UAs might display the alternate.  
Having a required attribute that is sure to be brief means that UAs  
can display that alternate in place of an image typically without   
disrupting the layout of the page.

>> So what I'm trying to discuss is whether that distinction (again
>> however it happened) is useful enough to preserve and even migrate to
>> other embedded content?
> I don't see how it helps authors.  Alternative content inside an  
> element
> already covers what both alt and longdesc provide:

The question is whether it's sufficient if an author includes lengthy  
equivalent fallback in the contents of an <object> element? Is there  
an algorithm we could recommend for extract a brief (@alt like)  
fragment in that situation? Again, I don't care all that much how we  
address this issue, just that we address it.

> * It doesn't have alt's disadvantage of not permitting mark-up.
> * It doesn't have longdesc's disadvantage of being hassle to use.

But its not clear how it can fulfill the role that @alt has taken on  
in relation to @longdesc.

On Jul 15, 2007, at 12:41 PM, Smylers wrote:
> Robert Burns writes:
>> On Jul 13, 2007, at 10:44 AM, Sander Tekelenburg wrote:
>>> I still have absolutely no idea why you list @title as a mechanism
>>> to provide an alternate/fallback. That's not at all what HTML 4.01
>>> says about  @title and I don't recall it's ever been different in a
>>> previous spec.
>> I list @title because if an author wants to provide <em> short</em>
>> descriptive information for a media file on an <object> element
>> (i.e., something that would show up in a text-only browser or get
>> handled in a non-visual UA), they would need to use @title to do so.
> Why?  Just because the content of <object> _can_ contain long or rich
> content, surely it can still be used for short text-only content in
> circumstances where a piece of short text is what best provides an
> alternative for those not viewing the object?

The issue I'm raising is not about that situation. Its about the  
situation when <object> contains long rich text. How then will a UA  
provide an @alt like rendering of that lengthy alternate text? At the  
minimum we should specify an algorithm for the UA to extract a piece  
of that text.

Take care,

Received on Monday, 16 July 2007 00:54:48 UTC