Re: [whatwg] Make radio button group suffering from being missing
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make radio button group suffering from being missing
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
Re: [whatwg] Make radio button group suffering from being missing
On Thu, 4 Nov 2010, Mounir Lamouri wrote: Currently, when a radio button is required, it will suffer from being missing if no radio elements in the radio button group is checked. However, radio elements in the group will not suffer from being missing if they do not have the required attribute. In other words, if you try to style invalid elements with :invalid, and do: input type='radio' name='s' value='M' required input type='radio' name='s' value='F' only the first element will be styled. I think we should move the requirement to the radio button group that way: The radio button group suffers from being missing if one of the input elements in the radio button group is required and all of them have a checkedness that is false. and radio elements would have this constraint: If the radio button group is suffering from being missing, the element is suffering from being missing.. That way, all radio elements in the same radio button group will have the same validity state. That would be less annoying for authors and error proof while making things clearer (IMO). 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. I'm thinking of implementing that for Gecko 2.0/Firefox 4 so I would like to know if you know any reason that would make the current behavior more appropriate than the one described here. 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? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Make radio button group suffering from being missing
On 11/29/2010 04:15 PM, Anne van Kesteren wrote: On Thu, 04 Nov 2010 01:20:37 +0100, Mounir Lamouri mounir.lamo...@gmail.com wrote: Currently, when a radio button is required, it will suffer from being missing if no radio elements in the radio button group is checked. However, radio elements in the group will not suffer from being missing if they do not have the required attribute. In other words, if you try to style invalid elements with :invalid, and do: input type='radio' name='s' value='M' required input type='radio' name='s' value='F' only the first element will be styled. I think we should move the requirement to the radio button group that way: The radio button group suffers from being missing if one of the input elements in the radio button group is required and all of them have a checkedness that is false. and radio elements would have this constraint: If the radio button group is suffering from being missing, the element is suffering from being missing.. That way, all radio elements in the same radio button group will have the same validity state. That would be less annoying for authors and error proof while making things clearer (IMO). I'm thinking of implementing that for Gecko 2.0/Firefox 4 so I would like to know if you know any reason that would make the current behavior more appropriate than the one described here. Do you have tests for this by any chance? I agree it makes sense to always treat them as a group. Yes, you can found them in the patch attached to this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=610687 -- Mounir
Re: [whatwg] Make radio button group suffering from being missing
On Thu, 04 Nov 2010 01:20:37 +0100, Mounir Lamouri mounir.lamo...@gmail.com wrote: Currently, when a radio button is required, it will suffer from being missing if no radio elements in the radio button group is checked. However, radio elements in the group will not suffer from being missing if they do not have the required attribute. In other words, if you try to style invalid elements with :invalid, and do: input type='radio' name='s' value='M' required input type='radio' name='s' value='F' only the first element will be styled. I think we should move the requirement to the radio button group that way: The radio button group suffers from being missing if one of the input elements in the radio button group is required and all of them have a checkedness that is false. and radio elements would have this constraint: If the radio button group is suffering from being missing, the element is suffering from being missing.. That way, all radio elements in the same radio button group will have the same validity state. That would be less annoying for authors and error proof while making things clearer (IMO). I'm thinking of implementing that for Gecko 2.0/Firefox 4 so I would like to know if you know any reason that would make the current behavior more appropriate than the one described here. Do you have tests for this by any chance? I agree it makes sense to always treat them as a group. -- Anne van Kesteren http://annevankesteren.nl/
[whatwg] Make radio button group suffering from being missing
Hi, Currently, when a radio button is required, it will suffer from being missing if no radio elements in the radio button group is checked. However, radio elements in the group will not suffer from being missing if they do not have the required attribute. In other words, if you try to style invalid elements with :invalid, and do: input type='radio' name='s' value='M' required input type='radio' name='s' value='F' only the first element will be styled. I think we should move the requirement to the radio button group that way: The radio button group suffers from being missing if one of the input elements in the radio button group is required and all of them have a checkedness that is false. and radio elements would have this constraint: If the radio button group is suffering from being missing, the element is suffering from being missing.. That way, all radio elements in the same radio button group will have the same validity state. That would be less annoying for authors and error proof while making things clearer (IMO). I'm thinking of implementing that for Gecko 2.0/Firefox 4 so I would like to know if you know any reason that would make the current behavior more appropriate than the one described here. -- Mounir
