[whatwg] Web Forms 2.0 Feedback
mpt at myrealbox.com
Fri Aug 27 23:58:34 PDT 2004
On 21 Aug, 2004, at 3:23 AM, Csaba Gabor wrote:
> 3. I'd like hierachical menus (pop up menus). Why can't an option
> element take other relevant HTML elements?
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.
> 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".
The distinction isn't made visually on most platforms, but on Mac OS
8.0 and later, the former has relatively rounded ends and never has an
icon, while the latter has relatively rectangular (or sometimes in OS
X, completely circular) borders and may have an icon. This presentation
is followed in Safari and in Opera for Mac.
> And for Pete's sake, have the spec say that access key properties must
> be reachable in a single key combination.
There are vastly more pages where type-ahead find is a more useful use
of unmodified keys than accesskey is, than pages where the reverse is
> 5. One thing that bothers me is that there are so many ways to
> plop a submit button on a page. You could make a link with an image,
> an <input type=submit onClick=...> element, an <input type=submit>
> element, a <button type=submit>, <button type=button onClick=...>,
> <input type=image ...>, <img ...>, image map, and probably I've left
> several out. This smacks of bloat. As I mentioned, one button type or
> another should be depracated.
There are lots of ways (other than the <Hn> elements) to make something
look like a heading in CSS. Maybe we should deprecate CSS too. ;-)
> 7. I've never understood why UAs render SELECT elements always on top.
> Can't we say/do something about that?
As far as I know, that's a combination of implementing both CSS and
non-sucky form controls. I doubt UAs are doing it out of negligence or
design, so "please stop being buggy" probably wouldn't achieve much.
> 9. You state in section 2.7 that the first option of a single select
> element is to be selected. However, this is in opposition to what you
> allow for radio buttons. And yet, single selects are essentially the
> equivalent of radio buttons, in a more compact form. If you allow
> radio buttons to be unselected, why not allow the single select
> element to be unselected, too?
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
More information about the whatwg