[whatwg] Suggestion for Menus in Web Forms 2.0

Matthew Thomas wrote:
> 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.

    I think you're imagining a constraint on WF2 that doesn't really
exist. WF2 can be used in chromeless windows. However, you many mean
that WF2 will primarily be used in a standard browser window, in which
case I would agree that a HTML-based menubar could cause confusion.

    Then again, I've seen Java applications in a browser that have such
menubars, so there may be a demand for this. Another thing is that
someone may want to create a simulated desktop interface where they can
open multiple "windows" within the browser windows. In that case, it
would be nice if these window-like blocks could have their own menubars.

    A lot of user confusion-type issues are possible here, so we should
probably discuss this at length.

> Web browsers already have their own menu bars, and allowing 
> these to be overridden would be highly confusing, if not a security 
> vulnerability.

    Agreed. Overriding the browser's own menus should be off the table.

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

    This is actually a bigger problem with non-chromed windows. (Unless
you were referring to the browser-menu-override situation.)

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

    One thing we could do is come up with a way to display menubars on a
few key operating systems that doesn't confuse users, then allow enough
room in the spec for user agent vendors to create their own solutions.

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

    I've seen quite a few sites that have horizontal navigational
buttons on the top, many with menus that drop down from those buttons.
There may actually be a significant demand for a properly stylable menubar.

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

    Why not simply have vertical and horizontal alignment for menubars?

    Personally, I wouldn't mind a better <link>, perhaps some better
styling rules and such, but most of the browser UI for <link> is
document centric. For instance, Mozilla 1.7 keeps common document
navigation buttons at the top level of the Site Navigation Bar, while
lesser used items are in submenus.

    Furthermore, HTML 4.01 allows support for <link> to implemented in
any way the UA vendor chooses, so suddenly turning <link> into a menu
system could cause serious problems. This is especially true if a
browser vendor chose to put <link> items in a submenu off the main
browser menu. We're better off creating a new menu structure instead.

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

    A bar can be vertical. I've seen many toolbars that can be
positioned that way. The Windows "Taskbar" can be vertical. I don't
really think this presents a serious conceptual problem.

    As for a default direction, I'd rather have CSS or an HTML attribute
handle it.

> That would suit the usual use case for adjacent 
> menus, and would avoid wrongly implying that it should look like a 
> native menu bar.

    On a chromeless window, it probably SHOULD look like a native menubar.

> Authors wanting horizontally adjacent menus could get 
> them without extra styling just by using adjacent <menu>s, without a 
> <menulist> element.

    How would they do this, by setting the |style| property equal to
"display: inline"? Keep in mind, an element name like "menubar" or
"menulist" can communicate more than just visual position. Native
menubar rendering on a chromeless window, for instance, would be
impossible without such an 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.)

    I don't mind presenting <menu> as a button when not in the context
of  a menubar. However, should this be required in the spec, or simply
recommended?

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

    You're confusing the implementation of a drop-down list for <select>
with the <select> element itself. The <select> element could be
implemented in a manner similar to that shown in the HTML 4.01
specification, for instance:

http://www.w3.org/TR/html401/images/optgroup_exmpl.gif

    The <select> element could be implemented as a pull-down menu.
Besides, in the context of using <select> WITHIN <menu>, a pull-down
menu would almost certainly be used.

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

    I understand that there are those who oppose submenus for good 
reason. I would personally agree that submenus should be used only when 
absolutely necessary. That said, I know from personal experience that 
there are applications that simply cannot do without submenus. 
Furthermore, I suspect that submenus will be most common in menu systems 
that have a fixed position, and therefore will be far less likely to 
break motor memory. Submenus are, unfortunately, a necessary evil.

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

    Easy to fix. Display the <option> |label| as in the menu and the 
child text of the <option> as the selection. This is consistent with the 
example from section 17.6.1 of the HTML 4.01 spec:

<FORM action="http://somesite.com/prog/someprog" method="post">
  <P>
  <SELECT name="ComOS">
   <OPTION selected label="none" value="none">None</OPTION>
   <OPTGROUP label="PortMaster 3">
     <OPTION label="3.7.1" value="pm3_3.7.1">PortMaster 3 with ComOS 
3.7.1</OPTION>
     <OPTION label="3.7" value="pm3_3.7">PortMaster 3 with ComOS 
3.7</OPTION>
     <OPTION label="3.5" value="pm3_3.5">PortMaster 3 with ComOS 
3.5</OPTION>
   </OPTGROUP>
   <OPTGROUP label="PortMaster 2">
     <OPTION label="3.7" value="pm2_3.7">PortMaster 2 with ComOS 
3.7</OPTION>
     <OPTION label="3.5" value="pm2_3.5">PortMaster 2 with ComOS 
3.5</OPTION>
   </OPTGROUP>
   <OPTGROUP label="IRX">
     <OPTION label="3.7R" value="IRX_3.7R">IRX with ComOS 3.7R</OPTION>
     <OPTION label="3.5R" value="IRX_3.5R">IRX with ComOS 3.5R</OPTION>
   </OPTGROUP>
  </SELECT>
</FORM>

    Unfortunately, IE, Mozilla and Opera ignore HTML 4.01 specified 
behavior regarding the |label| property of the <option> element:

http://bugzilla.mozilla.org/show_bug.cgi?id=40545

Received on Friday, 6 August 2004 20:50:44 UTC