- From: Jason White <jason@jasonjgw.net>
- Date: Mon, 6 Aug 2007 11:36:39 +1000
- To: public-html@w3.org
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