W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2008

[whatwg] Select elements and radio button/checkbox groups [Was: Form Control Group Labels]

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 2 Dec 2008 08:01:50 +0000 (UTC)
Message-ID: <Pine.LNX.4.62.0812020748320.17414@hixie.dreamhostps.com>
On Wed, 29 Oct 2008, Markus Ernst wrote:
> 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="gender">Gender:</label>
> > > <select id="gender" name="gender" type="boxgroup">
> > >   <option value=""> </option>
> > >   <option value="m">Male</option>
> > >   <option value="f">Female</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.

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.


> 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."

A few seconds with Emacs or any other editor with real search-and-replace 
tools and you're done.


> 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";

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.


> 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.

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.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 2 December 2008 00:01:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:46 UTC