[whatwg] Make radio button group suffering from being missing

[Ian Hickson]

On Wed, 12 Jan 2011, Mikko Rantalainen wrote:
> 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.

This is an interesting argument.

I haven't gone this way, mostly because having an explicit option that 
isn't a valid option seems like rather odd UI. If it turns out that people 
do this a lot (you can do it with script and setCustomValidity(), e.g.) 
then we should consider adding a new attribute for this specifically.

I did, however, change the spec to say that required="" only has to be set 
on one <input type=radio> to make all of them be required, and all of them 
be invalid, which hopefully makes this somewhat more understandable. (This 
change was actually made a while ago in response to other feedback.)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'