[whatwg] Web Forms 2.0 Feedback

[Matthew Thomas]

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

> ...
> 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 
backward-compatible.)

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