- From: Matthew Thomas <mpt@myrealbox.com>
- Date: Sat, 28 Aug 2004 18:58:34 +1200
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/
Received on Friday, 27 August 2004 23:58:34 UTC