- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 22 Aug 2009 01:42:08 +0000 (UTC)
On Fri, 18 May 2007, Lachlan Hunt wrote: > Ian Hickson wrote: > > In response to overwhelming feedback on this issue (especially in > > blogs, forums, and mailing lists other than this one, like www-html > > and public-html) I've removed the predefined classes. They're opaque > > again. > > > > The main use cases for predefined classes can mostly be dealt with > > using some of the new elements. class=note and class=example, for > > instance, can instead use <aside> elements, class=copyright can use > > <small>, etc. > > The use cases for "error", "warning" and "search" aren't yet covered > well with other elements. > > * class="search" > > The aim of this one was to be able to indicate the form specifically > used for searching. This would then allow UAs, especially assistive > technology, to implement keyboard shortcuts or other mechanisms for > taking the user directly to the search form. role="search" is provided > by the role attribute spec for a similar purpose, and Safari also has > <input type="search">. I would prefer the new input type because it > also has direct benefits for regular users, not just those with > assistive technology. I've added <input type=search>, and made it possible to set role=search on elements like <section>. > * class="error" > > The original idea for this was for indicating error messages, particularly > related form fields. The problem is that screen readers, when in forms mode, > only read the content of form control labels, which has resulted in authors > having to write any error messages within labels, which is kind of a hack. > Labels and error messages should be able to be separated and providing a way > to specifically indicate them would allow screen readers to indicate their > presence to the user and read it on request. > > * class="warning" > > This is similar to "error", but I can't recall the specific use cases. <output> and the various live region features in ARIA now take care of these. > There are various possible solutions to replace error and warning, some > of which include the following. (This is just brainstorming, neither of > these are particularly well thought out ideas.) > > 1. New <attn> element (short for 'attention'), which is specifically for > attracting the users attention, which is exactly what errors and > warnings do. > > 2. A new attribute on <label> to associate it with a related error message. > e.g. <label for="ctrl" attn="ctrl-error">Foo</label> > <input id="ctrl"> > <span id="ctrl-error">You filled in an incorrect value</span> > > The <attn> element is more generic and could probably solve other > similar use cases, whereas the the label attribute would only > specifically solve the form error use case. On Thu, 17 May 2007, Jon Barnett wrote: > > I like the idea of an <attn> element more than the other given ideas for > associating a message with a form or form control. It should have a "for" > attribute, like label: > <label for="password">Enter your new password</label><input > id="password"><attn for="password">Your password is too short</attn> > > In combination with a "role" attribute, it would solve issues with form > controls: > <label for="password">Enter your new password</label><input > id="password"><attn for="password" role="error">Your password is too > short</attn> > > An <attn> can attach to <form> and <fieldset> elements as well. > <form id="login"><attn role="error" for="login">Logging in was > unsuccessful</attn>...</form> > > There might be a use case were <attn> might be able to attach to other > non-form elements. I can't think of a compelling one. > > (The idea of an "attn" attribute above leaves the error message twice > removed from its form control) I haven't added this, I'm not sure the use case is compelling enough. > I like the idea of a "role" attribute for reasons other than that it's new > and doesn't conflict with exiting "class" attributes. Authors assume that > the class attribute is theirs to use for scripting and styling without > outside interference from the UA. Author's don't assume this about the > "rel" attribute. Authors assume that the UA will assign meaning and > function to the "rel" attribute, such as rel=next. HTML4 leaves the > possible values for "rel" open-ended, but authors don't use it willy-nilly. > However, rel=nofollow exists because UAs decided to support it. "role" > should have the same type of existence. > > I don't think XHTML2's example values for "role" are useful (except "note" > and "search"). "error" and "warning" are good useful examples. In the same > vein, I would add "confirmation" or "success". "role" is now owned by ARIA, for all intents and purposes. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 21 August 2009 18:42:08 UTC