Re: Marking up alternative versions of content

On Sun, Aug 05, 2007 at 03:42:45PM +0200, Sander Tekelenburg wrote:
 >
> > This is a good point. Such behaviour could be mandated by specifying that the
> > type of the element to which the FOR attribute of ALT refers must be one of
> > IMG, EMBED, AUDIO and VIDEO.
> 
> Hm... I'm not sure I understand. Why would it have to be limited to those
> specific elements, and why would it have to be limited to any specific
> element at all?

It is being proposed as a means of marking up alternatives to media elements
and images. If there are use cases for providing alternatives to other
elements, then I have no objection to allowing its application to them as
well. However, if the intent is to restrict it to images and media elements,
then <alt for=idref> where idref refers to another type of element, should
result in a validation error, as it is then a mistake on the part of the
author.
> 
> > If a full hierarchy of alternatives were permitted, though, it could be
> > marked up by having each successive ALT element in the hierarchy referring,
> >in
> > its FOR attribute, to its predecessor:
> > Schematically:
> > <embed [...] id="a">
> > <alt for="a" id="b"> [...]
> > <alt for="b" id="c"> [...]
> >
> > where b is the fallback for a, and c is the fallback for b. Structurally,
> >this
> > is somewhat analogous to a linked list.
> 
> Hm... That's an interesting idea.
> 
> I'm not sure it would work though. It seems risky to rely on authors making
> no mistakes. 
 
 Nested ALT elements are another possibility, similar in semantics to nested
 <object>, again assuming that a full hierarchy is desired. This would be less
 prone to error on the author's part, I expect.
> Btw, the risk of @for pointing to a non-existing id exists anyway. How could
> that be handled? It seems simple to say that in that case the UA must render
> the <alt> element, even if it is set to display:none. That would be a good
> enough error recovery for users. But it might be too challenging for UAs?

I don't know - that's a good question for UA implementors. It has the
advantage of making the error highly visible to authors during testing. It
should also be a validation error.
> 
>> However, it remains true that <alt> could serve as a substitute for both @alt
> > and @longdesc, with the TITLE attribute of <alt> replacing @alt, and its
> > content replacing @longdesc.
> 
> I'm not sure I agree with that last bit. I see @alt and @longdesc as a single
> two-piece hack to overcome the unique problems of <img>. Each serves one half
> of the same goal. A poor solution. <object> doesn't have either @alt or
> @longdesc, because its content can be long or short, rich or poor. Its
> alternate markup mechanism needs not be split into multiple parts.
> 
> Coming from that view, I'd think that the content of <alt> would replace both
> @alt and @longdesc. With <alt>, there is no longer a need to think in terms
> of <img>'s split fallback personality, and I think that would be very
> healthy. So I'd say that <alt>'s @title should definitely *not* contain an
> equivalent. It should contain *advisory information* about that particular
> <alt>.

I agree, though I would argue that where @alt and 2longdesc both exist in HTML
4, @alt is effectively providing advisory information about the resource
referred to by @longdesc.

In practical terms, if an author has written multiple paragraphs of
explanation as the content of <alt>, there is considerable value, from the
user's point of view, in having a short label or summary in the TITLE
attribute of <alt> so that one can decide whether and when to read the
detailed explanation. Although this may be characterized as advisory
information, it would require something better than title="description of
image" or title="transcript of audio".

These are authoring considerations appropriate for usage guidelines rather
than for inclusion in the spec, but I do want to point out the value of having
both a short and a long alternative, and of using @title to convey the summary
information that can be used to decide whether to read the full alternative.
> > @alt is unlikely to be deprecated, as it is a required attribute,
> 
> What would it mean if @alt and/or @longdesc are kept in HTML5? Would that not
> discourage authors to use <alt>? Would it not make some authors, trying to
> cater for legacy UAs, do stuff like this:
> 
> <img id="blah" src="URL" alt="short textual equivalent" longdesc="URL">
> <alt for="blah" type="text/html" title="marked up text">single long or short
> marked up equivalent</alt>
> 
> Which would result in multiple of the same (or actually not the same, due to
> the split between @alt and @longdesc) equivalents in legacy UAs, *and* in
> HTML5 UAs.
> 
> <blasphemy>
> In short, unless I'm overlooking something, it would seem that if we would go
> for <alt>, we would need to deprecate @alt and @longdesc. With <alt> they're
> not needed and actually in the way. Let's give'm a nice burial ceremony and
> move on.
> </blasphemy>

I would be glad to join you in doing so.

Received on Monday, 6 August 2007 01:36:59 UTC