[whatwg] Suggestion for Menus in Web Forms 2.0

[Ian Hickson]

On Thu, 26 Aug 2004, Matthew Thomas 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.

Hitting enter would cause the page to just load normally in the browser. 
It would be stupid for the default to be "trust this site".


> >   ::      (( 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) ...

How about:

  :::: Security Warning :::::::::::::::::::::::::::::::::::::
  ::                                                       ::
  ::  This Web page wishes to launch an application in a   ::
  ::  separate window. Do you trust this domain?           ::
  ::                                                       ::
  ::     paypcl.com                                         '
  ::
  ::             ( Trust this site for now )
  ::
  ::              ( Always trust this site )
  ::
  ::              (( Display as Web page ))
  ::
  :::::.

Would that be better?


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

You're assuming that we give the pages a way to tell if they are running 
in a Web browser or "as a native application". It could definitely see 
strong arguments for not making it possible to distinguish the two.


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

You can always find bad UI, you certainly don't have to give authors 
access to a native menubar to do _that_.


> > 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?

Well, both, in a way.

The idea of preventing _menus_ (as in context menus, and the dropping-down 
parts of menu bars) from being rendered by default is definitely a 
feature. It means that the options don't clutter the page until they are 
selected. (There are ways to use the proposed features to display the 
menus in fallback content if that is wanted, but that's another story.)

The problem here is with menu _bars_. That menu bars would show different 
content when handled natively vs when handled by CSS seems like a problem.

I suppose one solution would be to say the markup would have to be:

   <menulist>
     <menulabel>File</menulabel>
     <menu>
       <command label="Save" ...>
       <command label="Save As..." ...>
     </menu>
     <menulabel>Edit</menulabel>
     <menu>
       <command label="Cut" ...>
       <command label="Copy" ...>
     </menu>
   </menulist>

...and that normal "submenu" definitions (<menu label="">) would have no 
effect.

Hmm. Let's try that.


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

Yes yes, this is all already defined by WA1. I'm just talking about the 
menu bar bit here.


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

To some extent. The way it's defined now, the <input>/<a>/<button>/<hr>/
<select> elements etc have to be children of the <menu> element (or <li> 
elements that are themselves children of the <menu>).

I suppose we could crawl the entire tree, but that would be quite a bit 
more complicated. Is it worth it?


> > > (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?

Sadly, yes.

I've seen people implement entire scrollbars in JS, including all the 
native scrollbar behaviour, just because they wanted Windows XP-styled 
scrollbars on other platforms, requiring _hundreds_ of lines of code 
despite the fact that the CSS equivalent is exactly one line long. The 
difference is that CSS doesn't let you style the scrollbars.


> > Nested optgroups don't imply submenus. Just more indented options with 
> > headers.
> 
> Well, that's not good design either ... 

Why not? I'm not saying it is, just curious as to why it isn't.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'