- From: Mikko Rantalainen <mikko.rantalainen@peda.net>
- Date: Wed, 12 Jan 2011 11:55:05 +0200
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
Received on Wednesday, 12 January 2011 01:55:05 UTC