- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 8 Jun 2011 22:23:46 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 8 June 2011 15:23:46 UTC