[whatwg] Suggestion for Menus in Web Forms 2.0

[Matthew Thomas]

On 5 Aug, 2004, at 10:46 PM, Ian Hickson wrote:
> ...
> The thing I'm still not really sure about is the whole thing of how to
> make it look like a menu bar when it is used inline, instead of being
> used in the actual menu bar.
> ...

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. Web browsers already have their own menu bars, and 
allowing these to be overridden would be highly confusing, if not a 
security vulnerability. For example, the previous discussions on this 
list about ensuring people can save or print their work would be 
somewhat irrelevant if applications could create fake menu bars with 
fake "Save As..." and "Print..." menu items that saved or printed 
something completely unexpected.

Hopefully you agreed that far already. :-)

Therefore, making <menubar> "look like a menu bar" would involve having 
two or more visually similar menu bars on the screen simultaneously. 
But this is bizarre behavior on some platforms, and even on platforms 
where it is expected behavior, it is highly confusing. For example, 
Microsoft considered it such a problem that in Windows 98 and later, 
they made native menu bars in non-frontmost windows look unavailable 
(even though they're not), in an apparent attempt to discourage people 
from using those menu bars by mistake. The other way Windows users 
lessen the confusion is by maximizing as many of their windows as 
possible, but that tactic would offer no respite from a <menubar> 
inside a browser window with its own menu bar.

However, ~90 percent of the Web apps I have seen trying to implement 
pull-down menus are just wanting single menus by themselves, in which 
cases <menubar> is not needed. Of the remainder that use multiple 
consecutive menus, perhaps half want a horizontal menu bar for 
navigation (which could possibly be satisfied by requiring UAs to 
implement <link> more reliably and attractively), and half want a 
vertical one (e.g. <http://msnbc.msn.com/>).

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

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

Submenus (even non-nested submenus) would be even worse in <select>s 
because the current selection varies the vertical position of all the 
other items, which in turn would vary the direction of every submenu 
(southeast, northeast, or east-ish), which would repeatedly break 
muscle memory of what direction particular submenu items were in, which 
would make them extremely slow and annoying to use. (Example: the 
<select> implementation in Netscape Navigator 3.0 for Unix, which used 
submenus instead of auto-scrolling.)

(The general problem with submenus is that they require multiple 
changes in direction, but if you click or release in the wrong place 
while using them you usually have to start your selection from scratch. 
This problem does not apply to tree controls, nor even to a chain of 
dependent <select>s.)

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.

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