- From: Anne van Kesteren <fora@annevankesteren.nl>
- Date: Fri, 13 Aug 2004 15:58:08 +0200
>>>> Is this really needed in light of the fact that <label> supports >>>> |accesskey|? >> >> Besides my other mail, the thing is that it is already supported, >> probably because page authors requested it or used it. Now would be a >> good time to standardize these implementations and use cases. > > I think the biggest reason some browsers have non-standard support > for |accesskey| on the <select> element is that many people don't use > <label> to label controls, and don't use <label>'s |accesskey| instead > of <input>'s as recommended in the HTML 4.01 specification. Many > webmasters simply use pure text as a label and use |accesskey| directly > on the controls with no regard for whether the control element has an > |accesskey| attribute or not. Like I pointed out in the other mail, by example, this isn't always possible. > It was probably a mistake making |accesskey| an attribute of <input> > in the first place, since <label> would otherwise be required for access > keys and therefore be more widely used. If anything, |accesskey| in > <input> should be depreciated to prevent the continuing use of labels > that have no semantic association to their controls. The specification is just fine. If something should change, it would be the tutorials that are supposed to teach people correct markup. (There are far to few good tutorials on the web. When I searched a local Google for XHTML, the first result I got was a translation of an English article published with MS Frontpage.) >> Like it was done with AUTOCOMPLETE, albeit less important. > > The |autocomplete| attribute didn't have a workaround using valid and > recommended HTML markup like <select accesskey=""> does. That workaround does not apply in all cases and isn't suitable for that reason. -- Anne van Kesteren <http://annevankesteren.nl/>
Received on Friday, 13 August 2004 06:58:08 UTC