[whatwg] Suggestion for Menus in Web Forms 2.0
ian at hixie.ch
Wed Aug 25 15:07:18 PDT 2004
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
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: ::
:: ...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.
<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>
<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>
In a legacy UA, that's going to have links before each menu, which is
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:
<command label="Save" ...>
<command label="Save As..." ...>
<command label="Cut" ...>
<command label="Copy" ...>
...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
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg