[whatwg] Suggestion for Menus in Web Forms 2.0
mpt at myrealbox.com
Thu Aug 26 03:34:16 PDT 2004
On 26 Aug, 2004, at 10:07 AM, Ian Hickson wrote:
> Well, we want to be able to do both, really. Have Web applications run
> inside browser chrome, and also have Web applications run as
> first-class applications. The latter would of course only be allowed
> if the user said that he trusted the site, and so forth, e.g. after
> being explose to a Web page that said:
> :::: Security Warning :::::::::::::::::::::::::::::::::::::
> :: ::
> :: The Web page at this domain: ::
> :: ':
> :: paypcl.com
> :: ...wishes to
At which point I stop reading and blindly hit Enter, because I'm a
human, and it's a prompt, and never the twain shall meet. (Yes, good
that you put it in the content area rather than in an alert, but that
doesn't alter its uncompromising promptiness.)
Five seconds later: Hmmm, hang on, was that paypal.com, or something
else? I can't remember. I'll just check the address field ... Oh drat,
there isn't one. And I can't turn it back on, either, because there's
no View menu any more.
> :: (( Trust paypcl.com )) ( Display as Web page )
I could pick on this particular implementation (for example,
would have to become "(( Trust www.lla…och.com ))", in which case
www.goohax0rz.evilpeoplelivehere.muahahaogle.com would become
"(( Trust www.goo…gle.com ))", and being used to such ellipsized
labels, people would accept the latter unthinkingly) ... But I won't,
because there's a much nastier aspect to allowing sites to replace the
UA menus, even optionally.
It's that in a few years, once HTML5 is widely implemented, authors
start doing this: "We don't allow copying, printing, saving, or viewing
source of articles on this site. To enter the site, please choose
'Enter Example.com' from the 'Enter Here' menu. To see the menu, you
must have allowed Example.com application rights ..."
And then there'll be those authors who create a menu bar of 20 menus,
and it seems fine on *their* platform (a wrapping multi-line menu bar
is only slightly more awful than multi-line tabs, and Microsoft already
uses the latter, so it can't be *that* bad, right?), oblivious to those
platforms where the menu bar is only ever a single line and menus that
don't fit are simply never shown. (That some of your menus are never
shown on a particular platform is much more obvious if you're a native
developer for that platform.)
> One of the problems at the moment is that the menu will be different
> if it is interpreted "natively" or if it is rendered just using CSS.
> example, this menu bar/list/whatever:
> <menu label="File">
> <command label="Save" ...>
> <command label="Save As..." ...>
> <menu label="Edit">
> <command label="Cut" ...>
> <command label="Copy" ...>
> ....would work fine if handled natively -- but the CSS version would
> show nothing at all.
Are you thinking of that as a bug, or a feature?
Conceptually, pull-down menus contain commands, boolean options, radio
options, separators, and submenus. Except for submenus, HTML already
has elements for these: <button>/<a href>, <input type="checkbox">,
<select>, and <hr>. If a collection of these was wrapped in a <menu>
container (together with a <menutitle>), a WA-supporting UA could
render it as a pull-down menu (ignoring any elements other than the
ones I've listed here and their <label>s). And in a WA-ignorant UA,
every item would still be usable; authors could even use <div>s,
<table>s, or whatever to optimize the layout for the non-menu case.
>> (Outside a <menulist>, UAs could present a <menu> as a button with a
>> downward-pointing triangle at the end of it, just like native
>> standalone pull-down menus. This would both advertise their
>> menu-ness, and avoid the confusion of them looking like a native menu
> This isn't what authors want, based on what you see on sites today.
Do you really think authors would reject the opportunity to drop their
code-heavy and (almost invariably) buggy JS-driven pull-down menus in
exchange for faster, lighter, more reliable native pull-down menus,
merely because those native menus were displayed with native-menu-style
triangles at the end of them? Or did you mean something else?
> Nested optgroups don't imply submenus. Just more indented options with
Well, that's not good design either ... Except in, uh, the mind of the
designer of Safari's View menu. *sigh* Never mind. Too many windmills,
not enough horses.
More information about the whatwg