[whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]

[Thomas Broyer]

On Thu, Dec 4, 2008 at 12:45 PM, Markus Ernst wrote:
> Eduard Pascual schrieb am 29.10.2008 18:37:
>>
>> On Wed, Oct 29, 2008 at 9:49 AM, Markus Ernst <derernst at gmx.ch> wrote:
>>>
>>> Consider a form with some quite big radio button groups, and now you have
>>> do
>>> add some more options. After you are done, your boss says: "Ok, great
>>> work... but this looks too ugly now, just change it into those dropdown
>>> kind
>>> of things."
>>
>> Honestly, this seems like a presentational issue to me. Isn't CSS3's
>> Basic UI module (http://www.w3.org/TR/css3-ui/) enough to handle that?
>> Correct me if I'm wrong, but it seems that the properties there would
>> allow you to present a radiobutton group as a dropdown menu, and
>> vice-versa.
>
> This CSS3 module is indeed an interesting approach, anyway I don't see in
> this spec how possible conflicts between the form structure and it's
> presentation can be avoided or handled. Start with:
>
> <select name="gender">
>  <option value="f">Female</option>
>  <option value="m">Male</option>
> </select>
>
> Now you can easily change the presentation into a radio button group, which
> is fine:
>
> <select name="gender" style="appearance:radio-group">
>
> But then an author does this:
>
> <select name="gender" style="appearance:checkbox-group">
>
> Now there is a conflict, as the form structure allows only a single
> selection, while the presentation allows a multiple one. This does not only
> affect the rendering of the element and the reaction to user actions, but is
> even likely to break the handling of the submitted value, as server-side
> handlers often expect either a single value or an array of values and are
> not configured to cope with both of them.

appearance != behavior

CSS3-UI is clear about it:
"""Similarly, the HTML4 <SELECT> element for example, provides a list
or menu of choices to the user. The meaning of the HTML4 <SELECT>
element is that it allows the user to make a choice, to choose
something among several alternatives. This says nothing about its look
and feel, and in fact, the "concept" of a HTML4 <SELECT> could be
visually implemented as a list-box, a popup-menu, or a group of
radio-buttons. Or a group of HTML4 checkboxes (<INPUT
type="checkbox">) could be styled to appear as a group of
radio-buttons, and yet, since those elements are still semantic
checkboxes, they can still be individually checked or unchecked,
rather than acquiring any kind of radio-button group semantic where
only one can be checked.
Each example of presentation has a different look and feel, but
maintains its original meaning, a choice (or choices) among several
alternatives. This proposal addresses only the former (look and feel),
not the latter (meaning)."""
 — http://www.w3.org/TR/css3-ui/#scope

(the rest of this section brings some additional info of interest in
this discussion, I won't quote it all here)

> Now consider some elements written by an even more stupid author:
>
> <select name="gender" style="appearance:password">
>
> <input name="field10" type="text" style="appearance:radio-group">
>
> <fieldset style="appearance:field">
>  [some checkboxes...]

I guess the UA would, respectively, "draw a password field" (and set
the "password" font and the "text" cursor), "draw the 'frame' that
generally groups radio buttons" and "draw a text field". The "option"
and "optgroup" child elements of the "select" would still be rendered
as "appearance: menu-item" (though without the "popup menu" behavior)
and the checkboxes within the fieldset as "appearance: checkbox"
inside the field. It wouldn't change the fact that the "select"
options are selectable one at a time, that the field's value be
editable and that the checkboxes be checkable.

That would be very bad-looking though ;-)

-- 
Thomas Broyer