[whatwg] Web Forms 2.0 Feedback
mpt at myrealbox.com
Tue Nov 9 17:49:01 PST 2004
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
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
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."
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
> 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.
More information about the whatwg