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
Re: [whatwg] a and button
Håkon Wium Lie wrote: I'd like to have a simple way of using button along with a to create pretty links. This markup works in Opera, Mozilla, and Webkit: a href=http://www.w3.org/;buttonW3C/button/a but it's not valid HTML5 it seems. I propose to make it valid. The inverse (a inside button) only works in Webkit. ... So a link that looks like a button? Maybe I'm missing something, but why would you ever want that? Users are trained that there's a difference between following links and pressing buttons, so it seems to be a bad idea to blur that distinction. Of course, buttons that look like links are a much bigger problem. BR, Julian
Re: [whatwg] a and button
On Mon, Oct 20, 2008 at 7:32 AM, Julian Reschke [EMAIL PROTECTED]wrote: Håkon Wium Lie wrote: I'd like to have a simple way of using button along with a to create pretty links. This markup works in Opera, Mozilla, and Webkit: a href=http://www.w3.org/;buttonW3C/button/a but it's not valid HTML5 it seems. I propose to make it valid. The inverse (a inside button) only works in Webkit. ... So a link that looks like a button? Maybe I'm missing something, but why would you ever want that? Users are trained that there's a difference between following links and pressing buttons, so it seems to be a bad idea to blur that distinction. Of course, buttons that look like links are a much bigger problem. BR, Julian Not really. To a user, a button just means press this to go to another page, possibly also submitting a form. We're well trained to accept buttons as plain links, though - just look at how many navs are styled in a button-like manner. Even within the context of press a button to do something with a form, it's reasonable to want your buttons and links styled the same. Say you have a Submit and a Cancel button. Submit would post the form, while Cancel would just be a bare link out to some other page. In this case, you want both to have similar looks so as to present a cohesive UI. (I have no particular opinion on Hakon's proposal, though. I get around this by never using plain buttons - mine are always styled in such a way that links can copy.) ~TJ
[whatwg] a and button
I'd like to have a simple way of using button along with a to create pretty links. This markup works in Opera, Mozilla, and Webkit: a href=http://www.w3.org/;buttonW3C/button/a but it's not valid HTML5 it seems. I propose to make it valid. The inverse (a inside button) only works in Webkit. Cheers, -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] a and button
On Sun, Oct 19, 2008 at 2:57 PM, Håkon Wium Lie [EMAIL PROTECTED] wrote: I'd like to have a simple way of using button along with a to create pretty links. This markup works in Opera, Mozilla, and Webkit: a href=http://www.w3.org/;buttonW3C/button/a but it's not valid HTML5 it seems. I propose to make it valid. The inverse (a inside button) only works in Webkit. Cheers, -hkon Håkon Wium Lie CTO °þe(R)ª [EMAIL PROTECTED] http://people.opera.com/howcome What's wrong with button style=text-decoration: underline; color:blueW3C/button ?
Re: [whatwg] a and button
Also sprach Philipp Serafin: a href=http://www.w3.org/;buttonW3C/button/a What's wrong with button style=text-decoration: underline; color:blueW3C/button It's not a link. I'd like for buttons to work as links so that they take me to a page when I click on them. -hkon Håkon Wium Lie CTO °þe®ª [EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] a and button
On Sun, 19 Oct 2008 16:09:11 +0100, Håkon Wium Lie [EMAIL PROTECTED]
wrote:
button style=text-decoration: underline; color:blueW3C/button
It's not a link. I'd like for buttons to work as links so that they
take me to a page when I click on them.
http://www.w3.org/TR/css3-ui/#appearance
a {appearance: button} should do that.
In current browsers:
form method=get action=url style=display:inlinebutton/form
is very close to a link.
--
regards, Kornel Lesinski
Re: [whatwg] a and button
Also sprach Kornel Lesinski:
It's not a link. I'd like for buttons to work as links so that they
take me to a page when I click on them.
http://www.w3.org/TR/css3-ui/#appearance
a {appearance: button} should do that.
Yes, that's a good proposal. However, it doesn't work in current browsers.
This markup works (in Mozilla, Opera, Webkit), and it looks pretty good:
a href=http://www.w3.org/;buttonW3C/button/a
So, I think HTML5 should describe it.
In current browsers:
form method=get action=url style=display:inlinebutton/form
is very close to a link.
Yes, this works:
form action=http://www.w3.org; style=display:inlinebutton
type=submitW3C/buttonform
But, the markup isn't pretty. Also, I'd like for links to use the a
element.
-hkon
Håkon Wium Lie CTO °þe®ª
[EMAIL PROTECTED] http://people.opera.com/howcome
Re: [whatwg] a and button
You need the WebKit prefix for it to work in WebKit. So it is: -webkit-appearance But it does work. On Oct 19, 2008, at 8:32 AM, Håkon Wium Lie wrote: Yes, that's a good proposal. However, it doesn't work in current browsers. — Timothy Hatcher
Re: [whatwg] a and button
This of course doesn't support open link in new window/tab, download
link, bookmark link, drag copy anchor, and history coloring.
not sure if i've missed anything.
a number of these things are actually browser bugs imo, but solving
them is non trivial (if not nearly np-hard)
On 10/19/08, Kornel Lesinski [EMAIL PROTECTED] wrote:
On Sun, 19 Oct 2008 16:09:11 +0100, Håkon Wium Lie [EMAIL PROTECTED]
wrote:
button style=text-decoration: underline; color:blueW3C/button
It's not a link. I'd like for buttons to work as links so that they
take me to a page when I click on them.
http://www.w3.org/TR/css3-ui/#appearance
a {appearance: button} should do that.
In current browsers:
form method=get action=url style=display:inlinebutton/form
is very close to a link.
--
regards, Kornel Lesinski
--
Sent from Gmail for mobile | mobile.google.com
Re: [whatwg] a and button
Am Sonntag, den 19.10.2008, 17:32 +0200 schrieb Håkon Wium Lie:
Also sprach Kornel Lesinski:
It's not a link. I'd like for buttons to work as links so that they
take me to a page when I click on them.
http://www.w3.org/TR/css3-ui/#appearance
a {appearance: button} should do that.
Yes, that's a good proposal. However, it doesn't work in current browsers.
Please, HTML 5 is not a place to offloat your frustration about
unimplemented CSS features. FYI, Both webkit and Mozilla have already
implemented parts of appearance, also it's a purely presentational
thing. That are two big points standing against your proposal.
Greetings,
--
Nils Dagsson Moskopp
http://dieweltistgarnichtso.net
Re: [whatwg] [WF2] Make button default to type=button
Simon Pieters wrote: For compatibility with IE, button should default to type=button instead of type=submit. button without type should default to button. button type=unknown should default to submit. That way, we could still introduce new button types in the future and have them fall back to submit, while retaining compat with IE. -- Lachlan Hunt http://lachy.id.au/
[whatwg] [WF2] Make button default to type=button
For compatibility with IE, button should default to type=button instead of type=submit. -- Simon Pieters
