[whatwg] Suggestion for Menus in Web Forms 2.0

[Matthew Thomas]

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, 
www.llanfairpwllgwyngyllgogerychwyrndrobwyll-llantysiliogogogoch.com 
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. 
> For
> example, this menu bar/list/whatever:
>
>    <menulist>
>      <menu label="File">
>        <command label="Save" ...>
>        <command label="Save As..." ...>
>      </menu>
>      <menu label="Edit">
>        <command label="Cut" ...>
>        <command label="Copy" ...>
>      </menu>
>    </menulist>
>
> ....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 
>> bar.)
>
> 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
> headers.

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.

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