- From: Leif Halvard Silli <lhs@malform.no>
- Date: Sat, 23 Aug 2008 05:46:01 +0200
- To: Ian Hickson <ian@hixie.ch>
- CC: Steven Faulkner <faulkner.steve@gmail.com>, public-html@w3.org, W3C WAI-XTECH <wai-xtech@w3.org>
Ian Hickson 2008-08-23 00.45: > The following arguments impacted the decision [...] [the idea to reject role="photo" in favour of alt="{photo}] > * Introducing attributes for features that are supposed to be an > indicator of a problem (lack of alt text, in this case) isn't good > language design, as it brings it too much into prominence. I don't see "lack of alt text" as "an indicator of a problem". But if we introduced @role, /then/ @alt would be come an indicator. Today, whether you write alt="" or alt="spacer", there is nothing which indicates any problem. Both could be wrong. Both validate. > * An attribute would almost certainly be copied around unintentionally > by authors leading to it being at least as unreliable as the special > syntax if not more. Should we anticipate1 that the role of a particular photo will change much and often depending on its context? For the photo website use case, I have proposed role="albumphoto". I do not think it would hurt much if that attribute would follow by if the image was copied to another context. Instead, it could help. There are a bunch of other possible @role-s which probably would work in many contexts: role=spacer, role=decor, role=potrait, role=mathexpression, role=text etc. Of course, an author should try to ensure he uses right role. But the danger of copy-pasting seems exaggerated in this case. > * An attribute introduces a whole class of extra conformance errors and > complications, such as what to do when it is used with or without the > alt="" attribute. I actually thought we were /looking/ for ways to do better validation - that's how I have understood Henri. Without @role, a validator cannot check much more than whether @alt is or isn't there. As for the what User Agents are to do when @alt is lacking and @role is present, well - I guess that should be a simpler thing to answer than the question of what the UA should do when neither @role nor @alt is present? The problems which can arrise when the @role value contradicts the content of the @alt mostly are that @alt may have text when it should have been empty (alt="spacer"). Or that it is empty when it should have had text. Both these are even today a problem, except that they are impossible to deteect. @role would at least make them detectable, and thus possible to act upon. > All the above led to what the spec says today, which is the alt={...} > idea. > > Since the above, however, it has been pointed out that one problem with > the alt="{...}" idea exists that wasn't previously considered, namely that > it makes it harder for systems that _are_ trying to automate alternative > text creation to do so, since they now have to avoid accidentally using > the {...} syntax. This dramatically lowers the attractiveness of the {...} > idea, leaving pretty much only omitting alt="" for these cases as a > least-worse option. Exactly that problem could be avoided by the introduction of @role, as you could link the syntax to the particular @role. (Having @role would not mean, in my view, that Flickr should not try to repair the lack of user-inserted @alt text. Like Al said, they should put their clever "something" there. But with role="albumphoto", they could do so wihtout having to think about having to avoid the {...} syntax.) -- leif halvard silli
Received on Saturday, 23 August 2008 03:46:53 UTC