Re: unifying alternate content across embedded content element types

Hi Sander,


On Jul 13, 2007, at 10:44 AM, Sander Tekelenburg wrote:

>
> At 17:26 -0500 UTC, on 2007-07-06, Robert Burns wrote:
>
>> On Jul 6, 2007, at 3:31 PM, Sander Tekelenburg wrote:
>
> [...]
>
>> The @alt attribute is
>> only available for <img>. Is it just because @longdesc is so
>> difficult to work with?
>
> As someone else explained, @alt is available only for <img> because  
> <img> is
> an empty element and thus needed to have some mechanism added to it  
> to be
> able to provide fallback. As the HTML 4.01 spec says, @alt is for a  
> short,
> required, alternative, @longdesc for a longer, non-required,  
> alternative.

I understand how this was treated in HTML 4.01. I'm trying to raise  
these issues to see if there's something more we can do on HTML5.

>> Or are there (now) other reasons to separate
>> alternatives into short and brief versus long and richly semantic.
>> Because if there are other reasons than perhaps we need to add @alt
>> to all the other embedded content elements too.
>
> I'm not aware of other reasons for @alt to exist than <img> being  
> empty.
> Which other elements would need @alt? Non-empty tags, such as  
> <object>, allow
> for rich fallback. Why would you want to impoverish that?

I'm not advocating impoverishing anything. I'm not even sure what  
that  sentence refers to. However, @longdesc  has been distinguished  
from @alt by the length and the semantic richness of the value it  
takes. So <img> now has two different kinds of fallback or alternate/ 
equivalent content.

>> To reiterate the list of alternate information available for non-text
>> media:
>>
>> 1) media-file-specific fallback content / accessibility hooks /
>> textual metadata
>> 2) the surrounding prose
>> 3) the <legend>
>> 4) alternate (fallback) content
>> 	a)  the rich fallback (sometimes through @longdesc otherwise through
>> the element's contents)
>> 	b) @alt (currently on <img> only)
>> 	c) @title (on everything embedded)
>
> 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.

> [...]
>
>>> Both @alt and @longdesc are about *alternatives*  to the
>>> image. @title
>>> is for a certain type of *additional* information.
>>
>> Would you say then that @title, in providing "additional"
>> information,, sufficiently fulfills the needs for brief alternate
>> description on all of the other embedded content elements (i.e.,
>> other than <img>)?
>
> No, because "additional" != "alternate".

However, on an <object> element that provided additional information  
in the @title attribute that would serve as an alternate for media- 
poor UAs. It might not be the only alternate, but it would be an  
alternate (just as the file metadata and media-specific fallback for  
the media file would serve as alternate content).

>
>> I hope that by taking the opposite tack of my first email, it is
>> clearer what I'm trying to say.
>
> Sorry, no, it isn't. I don't understand what makes you say that  
> @title has
> anything to do with alternative content/fallback. I don't  
> understand why
> you'd say other elements than <img> need @alt. (Maybe you're  
> playing the
> devil's advocate, but then still I don't understand what point  
> you're trying
> to make.)

The <img> element has two separate alternate mechanisms: @alt and  
@longdes. Each has been given separate roles for alternate content:  
@alt short plain-text and @longdesc semantically rich lengthier  
text.  So the question I'm trying to pose is why two on <img> and not  
two on the other embedded content elements (and why none on <embed>)?

>> That is I'm not advocating for
>> replacing @alt with @title. Rather, I'm trying to unify, as much as
>> possible, how we use these various embedded content elements.
>
> My impression is it is all quite unified already. Non-empty  
> elements allow
> for rich fallback 'automatically'. <img> is the only exception. I  
> would like
> to get rid of that exception exactly because @alt is so poor. One  
> option is
> to encourage authors to use <object>, which will require that IE  
> gets fixed.
> Another is to add a new element, like <picture>.
>
> Because either solution will still mean <img> remains allowed, I  
> proposed
> that @alt and @longdesc are at least improved in HTML5:
> <http://esw.w3.org/topic/HTML/LongdescRetention#head- 
> ef01c5377a967ead313aeecea431de086517670a>.

I too want to seem <img> (and I would add <embed>) improved for the  
short-run. Again, I'm trying to understand why we need two different  
alternates on <img> (and different in how authors are guided to use  
them), but why we don't  also need those two different mechanisms  
(semantically rich and short and plain) on the other embedded content  
elements (I only raised @title to ask if that fills in this gap  
sufficiently).

I hope this is clearer.

Take care,
Rob

Received on Friday, 13 July 2007 20:16:19 UTC