On Sat, 21 Jan 2006 13:54:34 +0100, James Graham <[EMAIL PROTECTED]> 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
