[whatwg] Definition of alt= attribute

[Jonny Axelsson]

On Sat, 21 Jan 2006 13:54:34 +0100, James Graham <jg307 at cam.ac.uk> wrote:
> Henri Sivonen wrote:

>> Alternatively, the tool makers could give up the requirement of  
>> human-supplied alt text and just generate an empty alt text by default  
>> without asking. (Considering that the tool itself--not just the author  
>> using it--will be judged by seeing if the output passes an automated  
>> conformance check, it is likely that the requirement of correct output  
>> will not be dropped because of the alt issue.)

> People seem to have passed this point by. the current specification of  
> alt as required makes it almost impossible to design a conforming HTML  
> editor that doesn't mess up the semantics of the attribute. Since many  
> (the majority?) of HTML pages are produced using some form of graphical  
> editor (often implemented using contentEditable or some other HTML+js  
> solution as part of a CMS), the spec should at least consider the needs  
> of editors as well as UAs.

As I have stated before [1], 'spacer' is arguably the element with the  
most semantic information (namely that this element is used for layout  
hacks only and can be ignored for every other purposes), losing  
information when replaced with <img src="./spacer.png" alt=""> because the  
UA now doesn't *know* that the image is useless, but can assume so based  
on factors like URL, image dimensions, content, and above all the  
specified empty 'alt' attribute. Going from 'img' to 'object' loses more  
information, to be exact the very 'alt' attribute to separate the useful  
 from the useless.

Obviously I don't want the 'spacer' element back, 'spacer' is obsolete  
with CSS if not before. But the loss of information is real. If a UA wants  
to do a best attempt for an 'object' in a context where the object itself  
can't be rendered the UA will know next to nothing about the object. Yes,  
'object' has fallback (which 'img' too could have had if it hadn't been  
defined to be EMPTY) so there is little dispute what to render, but it  
doesn't know what it has missed. Depending on the object and the fallback  
the fact that the preferred content wasn't rendered can be anything from  
inconsequential to critical.

The danger with making an aspect of a markup language mandatory, like the  
mandatory 'alt' attribute for 'img' and the mandatory 'title' element in  
'head' is that the editor/author will need to use filler content that may  
reduce the quality of the attribute/element in question. With 'alt' this  
has the consequence 'alt=""' means either that this image has no alternate  
representation (and presumably semantic content) or that it has been  
automatically been filled in to make the document validate. It is fairly  
acceptable, but it would have been better that no 'alt' attribute at all  
had been used in the latter case.


Another datum that is lost from 'img' to 'object' is that the embedded  
object is supposed to be an image, and not e.g. an embedded HTML document,  
an applet or a video. In theory the content type could have given that  
information (text/*, image/*, audio/*...), but the 'type' attribute is  
optional, and in any case the non-informative application type is very  
common.

In this aspect (and not that many other) I like SMIL. In addition to 'ref'  
(the general 'object') it has 'animation', 'audio', 'img' (like HTML),  
'text', 'textstream', and 'video'.

[1] <http://my.opera.com/jax/blog/show.dml/83408>

-- 
Jonny Axelsson, Core Technology, Opera Software ASA