Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
On Thu, 4 Dec 2008, Markus Ernst wrote: Ian Hickson schrieb: Why is that a problem? Is converting one to the other a common occurance? I'm not really convinced it's that much work. Assuming that the radio buttons and/or checkboxes are written in a consistent manner, which they usually are, a simple regexp search-and-replace on the source is usually enough to convert them. [...] Well, as far as I get the various discussions in the WHATWG list, many of them are about one of the following: - Making things easier - Introducing features into HTML that are commonly solved by client-side (e.g. the extensions to the input element) or server-side scripting (e.g. solving the login/logout problem in HTML) Thus the question, is converting select to radio/checkbox groups common? I don't think it is. Are there oft-used JS libraries that do this? - Improving language consistency (e.g. the discussions about elements such as abbr, dfn, small, b etc.) These carefully avoid changing the syntax, though. :-) So let me, as a conclusion, repeat two points out of the suggestions I made earlier, which I think would be quite helpful, and which do not cause backwards compatibility problems, as they degrade to the default behaviour of the elements in older UAs. After that I will not insist in this topic anymore... :-) 1. Introduce a type attribute to the select element, which can change the output into a list of radio buttons (in normal mode) resp. checkboxes (in multiple mode). Why can't you just use input type=radio/input type=checkbox? (Note: On the long term, this is really just a stylistic issue, and XBL2 with CSS will be able to achieve this anyway.) 2. Introduce a multiline attribute to input type=text, possibly supplemented by a rows attribute. Why can't you just use textarea? We don't want to add features that don't really add new abilities, unless they really help something that people do a lot. Do people do this a lot? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
On Thu, 4 Dec 2008, Markus Ernst wrote: This CSS3 module is indeed an interesting approach, anyway I don't see in this spec how possible conflicts between the form structure and it's presentation can be avoided or handled. Start with: select name=gender option value=fFemale/option option value=mMale/option /select Now you can easily change the presentation into a radio button group, which is fine: select name=gender style=appearance:radio-group But then an author does this: select name=gender style=appearance:checkbox-group Now there is a conflict, as the form structure allows only a single selection, while the presentation allows a multiple one. It's not clear that the underlying element can actually get multiple selections here (I would argue it cannot); but this is an issue for CSS3 UI, not for HTML5. This does not only affect the rendering of the element and the reaction to user actions, but is even likely to break the handling of the submitted value, as server-side handlers often expect either a single value or an array of values and are not configured to cope with both of them. A conforming browser wouldn't send values that violate the rules HTML5 describes, which in this case prevents the scenario you describe, regardless of the presentation layer. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
Ian Hickson schrieb: [...] Why is that a problem? Is converting one to the other a common occurance? I'm not really convinced it's that much work. Assuming that the radio buttons and/or checkboxes are written in a consistent manner, which they usually are, a simple regexp search-and-replace on the source is usually enough to convert them. [...] A few seconds with Emacs or any other editor with real search-and-replace tools and you're done. [...] Changing the few lines of code it takes to write a bunch of radio buttons into the few lines of code it takes to write a select is easy. [...] I agree entirely that if one is designing the language from scratch it makes sense to be consistent. I'm not sure it makes sense to retroactively change the language to impose consistency on it. Well, as far as I get the various discussions in the WHATWG list, many of them are about one of the following: - Making things easier - Introducing features into HTML that are commonly solved by client-side (e.g. the extensions to the input element) or server-side scripting (e.g. solving the login/logout problem in HTML) - Improving language consistency (e.g. the discussions about elements such as abbr, dfn, small, b etc.) So I don't think that your arguments do not necessarily make my thoughts obsolete. Anyway I see the facts that WF2 is declared feature complete, that backwards compatibility has a very high priority, and that making form controls more consistent may not be crucial for WF2. So let me, as a conclusion, repeat two points out of the suggestions I made earlier, which I think would be quite helpful, and which do not cause backwards compatibility problems, as they degrade to the default behaviour of the elements in older UAs. After that I will not insist in this topic anymore... :-) 1. Introduce a type attribute to the select element, which can change the output into a list of radio buttons (in normal mode) resp. checkboxes (in multiple mode). 2. Introduce a multiline attribute to input type=text, possibly supplemented by a rows attribute.
Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
Eduard Pascual schrieb am 29.10.2008 18:37: On Wed, Oct 29, 2008 at 9:49 AM, Markus Ernst [EMAIL PROTECTED] wrote: Consider a form with some quite big radio button groups, and now you have do add some more options. After you are done, your boss says: Ok, great work... but this looks too ugly now, just change it into those dropdown kind of things. Honestly, this seems like a presentational issue to me. Isn't CSS3's Basic UI module (http://www.w3.org/TR/css3-ui/) enough to handle that? Correct me if I'm wrong, but it seems that the properties there would allow you to present a radiobutton group as a dropdown menu, and vice-versa. This CSS3 module is indeed an interesting approach, anyway I don't see in this spec how possible conflicts between the form structure and it's presentation can be avoided or handled. Start with: select name=gender option value=fFemale/option option value=mMale/option /select Now you can easily change the presentation into a radio button group, which is fine: select name=gender style=appearance:radio-group But then an author does this: select name=gender style=appearance:checkbox-group Now there is a conflict, as the form structure allows only a single selection, while the presentation allows a multiple one. This does not only affect the rendering of the element and the reaction to user actions, but is even likely to break the handling of the submitted value, as server-side handlers often expect either a single value or an array of values and are not configured to cope with both of them. Now consider some elements written by an even more stupid author: select name=gender style=appearance:password input name=field10 type=text style=appearance:radio-group fieldset style=appearance:field [some checkboxes...] ...
Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
On Thu, Dec 4, 2008 at 12:45 PM, Markus Ernst wrote: Eduard Pascual schrieb am 29.10.2008 18:37: On Wed, Oct 29, 2008 at 9:49 AM, Markus Ernst [EMAIL PROTECTED] wrote: Consider a form with some quite big radio button groups, and now you have do add some more options. After you are done, your boss says: Ok, great work... but this looks too ugly now, just change it into those dropdown kind of things. Honestly, this seems like a presentational issue to me. Isn't CSS3's Basic UI module (http://www.w3.org/TR/css3-ui/) enough to handle that? Correct me if I'm wrong, but it seems that the properties there would allow you to present a radiobutton group as a dropdown menu, and vice-versa. This CSS3 module is indeed an interesting approach, anyway I don't see in this spec how possible conflicts between the form structure and it's presentation can be avoided or handled. Start with: select name=gender option value=fFemale/option option value=mMale/option /select Now you can easily change the presentation into a radio button group, which is fine: select name=gender style=appearance:radio-group But then an author does this: select name=gender style=appearance:checkbox-group Now there is a conflict, as the form structure allows only a single selection, while the presentation allows a multiple one. This does not only affect the rendering of the element and the reaction to user actions, but is even likely to break the handling of the submitted value, as server-side handlers often expect either a single value or an array of values and are not configured to cope with both of them. appearance != behavior CSS3-UI is clear about it: Similarly, the HTML4 SELECT element for example, provides a list or menu of choices to the user. The meaning of the HTML4 SELECT element is that it allows the user to make a choice, to choose something among several alternatives. This says nothing about its look and feel, and in fact, the concept of a HTML4 SELECT could be visually implemented as a list-box, a popup-menu, or a group of radio-buttons. Or a group of HTML4 checkboxes (INPUT type=checkbox) could be styled to appear as a group of radio-buttons, and yet, since those elements are still semantic checkboxes, they can still be individually checked or unchecked, rather than acquiring any kind of radio-button group semantic where only one can be checked. Each example of presentation has a different look and feel, but maintains its original meaning, a choice (or choices) among several alternatives. This proposal addresses only the former (look and feel), not the latter (meaning). — http://www.w3.org/TR/css3-ui/#scope (the rest of this section brings some additional info of interest in this discussion, I won't quote it all here) Now consider some elements written by an even more stupid author: select name=gender style=appearance:password input name=field10 type=text style=appearance:radio-group fieldset style=appearance:field [some checkboxes...] I guess the UA would, respectively, draw a password field (and set the password font and the text cursor), draw the 'frame' that generally groups radio buttons and draw a text field. The option and optgroup child elements of the select would still be rendered as appearance: menu-item (though without the popup menu behavior) and the checkboxes within the fieldset as appearance: checkbox inside the field. It wouldn't change the fact that the select options are selectable one at a time, that the field's value be editable and that the checkboxes be checkable. That would be very bad-looking though ;-) -- Thomas Broyer
[whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
Ian Hickson schrieb: On Tue, 28 Oct 2008, Markus Ernst wrote: [...] I consider a total re-thinking of select, input type=checkbox and input type=radio elements as highly desirable, though I see that this might cause more serious backwards compatiblity problems than for example removing the font tag. One possible solution could be using the select tag with a type attribute: label for=genderGender:/label select id=gender name=gender type=boxgroup option value= /option option value=mMale/option option value=fFemale/option /select I don't understand what problem you are trying to solve here. Changing a group of radio buttons resp. checkboxes into a select element, or vice-versa, needs a non-trivial amount of work. This applies to both HTML coding and DOM access. Consider a form with some quite big radio button groups, and now you have do add some more options. After you are done, your boss says: Ok, great work... but this looks too ugly now, just change it into those dropdown kind of things. Also, if you want to achieve the same via DOM access requires quite some coding amount, you have to build a totally different tree of elements, instead of one line: document.getElementById(gender).type = dropdown; On Tue, 28 Oct 2008, Tab Atkins Jr. wrote: I haven't given it serious thought, but as far as I can tell his proposed solution (piling all four display types onto the select tag) would work wonderfully as a semantic consolidation/simplification, and be nicely backwards-compatible. There are still good reasons to support keeping the input types of radio and checkboxes, of course (frex, wrapping a form around a list, and putting an input within each li), but this proposal would simplify the most common case. I don't see what problem this solves. What's wrong with what we have now? We have similar things treated in different ways. To illustrate this, have a look unordered and ordered lists, which are similar, too. Consider ul and ol would have the same kind of different syntaxes; say, the ul element would work like we know it, but to make an ordered list we would have to write something like: p type=orderedlist listposition value=list position 1 listposition value=list position 2 /p Now simply changing an ordered into an unordered list would cause an annoying amount of re-writing, such as changing a radio button group into a select element does.
Re: [whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]
On Wed, Oct 29, 2008 at 9:49 AM, Markus Ernst [EMAIL PROTECTED] wrote: Consider a form with some quite big radio button groups, and now you have do add some more options. After you are done, your boss says: Ok, great work... but this looks too ugly now, just change it into those dropdown kind of things. Honestly, this seems like a presentational issue to me. Isn't CSS3's Basic UI module (http://www.w3.org/TR/css3-ui/) enough to handle that? Correct me if I'm wrong, but it seems that the properties there would allow you to present a radiobutton group as a dropdown menu, and vice-versa. To illustrate this, have a look unordered and ordered lists, which are similar, too. Consider ul and ol would have the same kind of different syntaxes; say, the ul element would work like we know it, but to make an ordered list we would have to write something like: p type=orderedlist listposition value=list position 1 listposition value=list position 2 /p Now simply changing an ordered into an unordered list would cause an annoying amount of re-writing, such as changing a radio button group into a select element does. Even in that case, CSS3 (and I think even CSS2) would perfectly allow you to render an originally unordered list as an ordered one (with different choices of numbering style), and vice-versa, without changing anything on the markup. In summary, if you only need to change the presentation, then it's a CSS issue (and CSS seems to deal well enough with it); and if you are really changing the semantics and inherent structure of the document, then the need to non-trivially adjust the markup is unavoidable: after all, the semantics and structure is what the markup is actually defining. Just my thoughts.
