[whatwg] Web Forms 2.0 Feedback

[Matthew Raymond]

Matthew Thomas wrote:
> On 9 Nov, 2004, at 12:56 PM, Ian Hickson wrote:
>> Given the number of people who request this feature, there is clearly a
>> demand. I'm not sure what the better solution to that demand is.
> 
> A tree control  
> <http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-July/ 
> 000856.html>. Yes, it would be larger than an option menu, but I  
> suspect authors using <optgroup> are more interested in the ability to  
> make single rather than multiple selections than they are in the size  
> of the control.

    As I've stated before, I see no reason not to use a tree control for 
<select multiple>. Nested <optgroup> elements in combination with 
<select multiple> naturally lend themselves to such a control.

    I personally think that we should focus on enhancing <select> and 
<select multiple> to add features including those similar to those 
available in WA1 menus, rather than trying to develop a completely new 
element.

>> Actually they're semantically identical. The only difference is that
>> <button> can have element content, and <input> can't.
> 
> Actually, buttons with rounded ends and buttons with rectangular ends  
> have had the semantic meanings I described above since Mac OS 8.0  
> (albeit that those meanings were not explicitly stated in the HIGs).  
> When <button> was introduced into HTML, UAs rendered it with  
> rectangular ends, while retaining rounded ends for <input  
> type="submit">. (This distinction was originally not apparent on  
> Windows, but it has become apparent since Windows XP.) This was  
> consistent with the native meanings because <input type="submit">  
> almost always opens a new page (and sometimes opens/closes a window),  
> whereas <button> is usually used for scripts to alter the content/state  
> of items within a page.
> 
> It is true that the semantics are currently happening by accident, and  
> they can be flouted if authors try hard enough, but they do exist. They  
> may not be worth keeping; conversely, they may be worth specializing  
> even further. (For example, Mac OS X introduces completely circular  
> buttons, primarily used for controlling playback of a media track.)

    Are any of the differences you described actually in the HTML 4.01 
specification? At first glance, I can't seem to find them. If the 
differences you describe are just the implementation decisions, then I'm 
not sure if they're truly semantic differences to begin with. Either 
way, I would agree that this needs to be discussed in detail.

    With regard to buttons with rounded and square corners, could you 
please explain the differences in how they're used, because from a 
purely graphical standpoint, they seem well into CSS territory.

> So when making your list of new block elements for HTML 5, for example,  
> ideally you should have a comparable list of elements and attributes  
> that are to be removed.

    I would agree that removed markup should be documented.

>>> Because that would be bizarre behavior for those people accustomed to
>>> the behavior of native option menus, i.e. most people who have used a
>>> computer. (And yes, I think unspecified radiogroups should default to
>>> selecting the first, too, but apparently that wouldn't be
>>> backward-compatible.)
>>
>> Yeah, the spec is merely describing what UAs do. UAs have tried to do
>> other things, but they always fall back on that behaviour because sites
>> actually depend on it now.
> 
> I noticed a couple of days ago that "ISO-HTML requires that at all  
> times one and only one of the radio buttons in a set be checked.  
> Initially, if none of the <INPUT> elements in a set of radio buttons  
> specifies CHECKED, then the user agent shall mark the first radio  
> button of the set as checked"  
> <http://www.cs.tcd.ie/15445/UG.HTML#I.RADIO>. Ah well.

    I oppose the idea of having no radio buttons in a radio group 
initially selected. Without some sort of default, there's no way to 
return to the initial state once you've clicked on an option. To allow 
unselected behavior is the functional equivalent of having a default 
option that disappears once you select something other than the default. 
It also creates the following two problems:

1) If you have to worry about options not being selected, you have to 
test to see if nothing was selected. In a strict security sense, the 
server should be checking anyway, but in practice this can trip up a lot 
of webmasters.

2) If the user fails to select an option from the radio group, is this a 
choice the user made, or did they fail to select an option by accident 
(by forgetting to select and option, paging past the radio group, et 
cetera)?