[whatwg] Suggestion for Menus in Web Forms 2.0

[Ian Hickson]

On Sat, 7 Aug 2004, Matthew Thomas wrote:
> 
> Allowing a native-looking menu bar makes sense for applications that are 
> going to have complete control over their own interface. However, the 
> What-WG specifications (as opposed to other specifications deemed too 
> ambitious and/or unmixable) are designed to be implementable inside Web 
> pages, where applications cannot have complete control over their own 
> interface.

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 launch an application in a separate
  ::  window. Do you trust this domain?
  ::
  ::  [x] Remember this decision.
  ::
  ::      (( Trust paypcl.com ))  ( Display as Web page )
  ::
  :::::.


> Therefore, I suggest the <menubar> element be renamed to <menulist>, to 
> indicate that (in graphical UAs) its child <menu>s will be rendered 
> vertically by default.

Here is where I ran into trouble.

Take:

<menubar>
 <li>
  <a href="#file">File</a>
  <menu id="file">
   <li><button type="button" onclick="fnew()">New...</button><li>
   <li><button type="button" onclick="fopen()">Open...</button><li>
   <li><button type="button" onclick="fsave()" id="save">Save</button><li>
   <li><button type="button" onclick="fsaveas()">Save as...</button><li>
  </menu>
 </li>
 <li>
  <a href="#edit">Edit</a>
  <menu id="edit">
   <li><button type="button" onclick="ecopy()">Copy</button><li>
   <li><button type="button" onclick="ecut()">Cut</button><li>
   <li><button type="button" onclick="epaste()">Paste</button><li>
  </menu>
 </li>
</menubar>

In a legacy UA, that's going to have links before each menu, which is 
pretty ugly.

In WA1 UAs, according to the draft, it's going to just be a list with two 
"menu links", links that have been styled specially, and which trigger the 
menus when activated.

Last time I thought of this I considered that maybe instead of <a> we 
should use <menulabel>. But I'm still not convinced the whole <menubar> 
(or <menulist> or whatever) rendering model is sound.

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.


> That would suit the usual use case for adjacent menus, and would avoid 
> wrongly implying that it should look like a native menu bar. Authors 
> wanting horizontally adjacent menus could get them without extra styling 
> just by using adjacent <menu>s, without a <menulist> element. (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.


> > There have been a lot of requests for nested OPTGROUPs, so I'm 
> > thinking maybe we should just allow them.
> 
> Nested submenus are less evil (though still HIG-contraveningly horrible) in
> pull-down menus (e.g. <menu>) than they are in option menus (e.g. <select>),
> because at least in pull-down menus a particular submenu item is usually in
> the same direction relative to its parent item. (This isn't *always* true on
> platforms that put menu bars inside windows, because the position of the
> window may force a menu or submenu to open *sometimes* to the north and/or
> west instead of the southeast.)

Nested optgroups don't imply submenus. Just more indented options with 
headers.


> Another reason not to have <optgroup>s inside <select>s is that option 
> menus are supposed to show their state even when closed, but they cannot 
> do so reliably if two or more submenus contain items with the same text. 
> For example, the distinction between the towns of "Australia" > 
> "Palmerston" and "New Zealand" > "Palmerston" would be obvious if a tree 
> control was used, or if two <select>s were used; but the distinction 
> could not be shown in a single native-looking option menu while the menu 
> was closed, without making the menu abnormally wide.

HTML4 already allows for this, by having two labels, one for the full case 
and one for the short case.

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