[whatwg] Web Forms 2.0 Feedback

[Matthew Thomas]

On 9 Nov, 2004, at 12:56 PM, Ian Hickson wrote:
> ...
> On Sat, 28 Aug 2004, Matthew Thomas wrote:
>> ...
>> Hierarchical option menus don't exist as a native control on the
>> platform used by ~95 percent of Web users, and even on those platforms
>> where they do exist, they're extremely difficult to use.
>
> In the current spec, <optgroup> may be nested, but this doesn't imply
> hiearchical menus like in the HTML4 spec. It would just mean indented
> options under headings, like you see in Windows sometimes (no examples
> come to mind, but I've seen it occasionally).

Bonus points if it wasn't shareware. Triple bonus points if it was  
anything produced by Microsoft, Adobe, Macromedia, Apple, Corel,  
Novell, Symantec, McAfee, Borland, or Quark.

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

>>> 4.  Does it make sense to have both an <input type=button/submit/
>>> reset... and <button type=... element.
>>
>> They're semantically different. The former does something that  
>> usually will open a new page (and/or open or close a window); for  
>> example, "OK", or "Insert Addresses...", or "Don't Save". The latter  
>> does something that usually won't open a new page (and/or open or  
>> close a window); for example, "Add Row", or "Remove Row", or "Play".
>
> 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.)

> ...
> Csaba's point is well-made, actually. I don't think anything in his  
> list warrants deprecation at this point, but it is definitely  
> important for us not to introduce too much redundant stuff. People  
> should not feel at all worried about suggesting that we're adding too  
> much.

Adding a little in each revision will eventually have the same effect  
as adding too much in a single version; the spec will become too  
complex for people to bother reading, so authors will copy-and-paste  
erroneous/inappropriate code from nearby pages instead of referring to  
the spec. (For example: "You can search for DOCTYPEs all day at w3.org  
without finding one page that lists them all. And when you do hunt down  
a DOCTYPE (generally in relation to a particular Recommendation or  
Working Draft), it's often one that won't work on your site."  
<http://alistapart.com/articles/doctype/>)

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.

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

-- 
Matthew Thomas
http://mpt.net.nz/