[whatwg] Make radio button group suffering from being missing

Mikko Rantalainen mikko.rantalainen at peda.net
Wed Jan 12 01:55:05 PST 2011


2011-01-08 00:06 EEST: Ian Hickson:
> The basic idea behind this design is that type=radio seems to have been 
> designed to keep each control as independent as possible -- before we 
> started fiddling with it in WF2, the only way type=radio controls had any 
> relationship to other type=radio controls was with their behaviour when 
> they were clicked. Now, for required="", we needed a little more than 
> that, because otherwise required="" was essentially useless for radio 
> buttons, but I tried to be faithful to the original design and kept it as 
> independent as possible.
> [...]
> In the end I'll spec whatever gets implemented. What do other browser 
> vendors feel about this? Should we make required="" on any one type=radio 
> control affect the validity of all the other controls? Or should we stick 
> to the independent basis of this API?

I'm not a browser vendor but my first opinion is that radio buttons
should use any @required attribute in the radio button group. Rationale:

1. [In case all inputs should have @required set instead of any input in
the radio button group:] From an author point of view, having a bunch of
radio input elements with @required attribute set is not intuitive at
all because end user cannot ever select all @required inputs in that case.

2. [In case any input having @required is enough:] I agree with Ian that
currently type=radio controls are almost independent. However, the way
@selected already works in a radio button group, the @required attribute
would match the behavior quite well. From author point of view, this
would seem a bit illogical, too: the end user is free to select some
other input but @required.

However...

Saying that, I'd prefer having explicit not-allowed selection in a radio
button group to represent the fact that something must be selected. That
way the end user could intentionally reset the radio button group to the
initial state. Should there also be support for UI style where radio
button group has an item initially selected that makes the group
suffering from being missing (logically one input type=radio in a radio
group would have both @selected and @not-allowed set)?

In the end, a reasonable compromise solution to these use cases would be
to add @required attribute to any acceptable radio button item. In that
case, the case where nothing is initially selected in a radio button
group would be represented with a source where every item in radio
button group had @required and none had @selected. On the other hand,
the style where one input had @selected initially could be represented
with markup where initial input had @selected but not @required and all
the other inputs had @required. That would be interpreted as a initial
selection of radio button item that is not allowed for the radio button
group (at least one other item has @required and the currently selected
item does not have @required, in other words, should not be considered
acceptable).

That would be a nice match for UI sometimes seen in web service EULAs:
[type=radio @selected] I do not accept license terms.
[type=radio @required] I accept the license terms.

-- 
Mikko




More information about the whatwg mailing list