[whatwg] Predefined classes are gone

[Ian Hickson]

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.   `._.-(,_..'--(,_..'`-.;.'