[whatwg] Menus and Toolbars

(If you're cc'ed, your opinion likely affects implementations of this and 
so your input is especially requested. See the question at the end. If you 
reply to this, please strip the cc list as the mailing list software will 
otherwise block your post for having too many cc's. Thanks.)

There's a big section in the spec that tries to do three things:

 * context menus
 * toolbars
 * menu buttons

Right now it's not implemented by anyone, though Firefox has a variant.

   http://whatwg.org/html/#the-menu-element

This section has two big problems:

1. Styling of toolbars and menu buttons is just not defined.

Toolbars could be a purely stylistic issue, to be solved either excluively 
by CSS, or CSS plus a component/widget binding model (whatever solution we 
end up with for that).

Menu buttons are a real widget, though, so we can't just leave them to CSS 
styling of <div>s, there needs to be some real styling going on. Right 
now, because of the algorithm mentioned in #2 below, this is very 
complicated. I'll get back to this.

(Styling for context menus is not a big deal, they just use native UI.)


2. Nobody is implementing it, in particular, the algorithm that converts 
HTML elements into a menu structure seems unpopular.

Right now, the spec has this algorithm that defines how to map existing 
HTML semantics to a context menu or menu button (or toolbar, though the 
latter is less important if we move to a pure-CSS rendering model for 
toolbars, since we'd just drop the algorithm for them then).

The idea here is that you don't have to use JavaScript to replicate the 
effects of existing semantics. For example, if you want a menu button 
which acts as a navigation mechanism, you just put <a> elements in your 
markup and they automatically get turned into menu items.

There's also a generic <command> element for when you don't need an 
existing element to be used. Firefox essentially only implements this, 
though it's called <menuitem> in Firefox. <command> also supports an 
attribute that points at other elements to indirectly define features.


To move forward on this, here are some proposals:

#1: Drop <menu> and all related features. I don't think we should do this, 
but if we can't get agreement on what to implement, this is the only 
option left, so it's on the table.


#2: A design that supports context menus and menu buttons using dedicated 
markup, with support for indirect defining of commands.

First, we make <menu type=""> take three values: "toolbar", which just 
means to render the element using CSS (the default value for legacy pages, 
too), and "context" and "button", which define menus. "context" menus 
would be hidden by default, "button" menus would render as a button, 
which, when clicked, shows the menu. contextmenu="" can be used to point 
to a <menu type=contextmenu>.

The <menu> element in "context" and "button" modes would only have three 
elements as descendants: <menuitem> elements, <menu> elements, and <hr> 
elements. (Or maybe no <hr>s, and we do separators by using groups of 
<menu> elements without labels.) Other children are ignored.

<menuitem> elements would just have a label="" attribute and, optionally, 
a command="" attribute. The command="" attribute would work as it does in 
the spec now, deferring to some existing element. When the menu item is 
selected, it would fire click on the <menuitem>, and then as a default 
action do whatever the action of the command="" is, if specified. (We can 
talk about whether to bother supporting icons in the <menuitem>, and if so 
how, especially given high-res screens, but that's a minor detail.)

With type=button, CSS would apply to the <menu> and <menuitem> elements, 
maybe with a limited set of properties applying. Long term, we look to XBL 
or Web components or whatever for styling.

We drop <command> entirely.


#2a: Same as #2, except we keep <command> as a way to introduce commands 
without using existing elements.


#3: We forget the non-JS case; so, the same as #2, but <menuitem> doesn't 
get a command="" attribute. We add radio menu items, checkbox menu items, 
and the like, over time, as features on <menuitem>. (Defined much like 
<command> has some of them defined today.)


#4: We do what the spec has now.


#5: We do what the spec has now, except we change the type=toolbar to just 
be rendered in CSS (and remove type=list, making toolbar the default).


#6: Your idea here.


So, implementors: Which of these would you be willing to implement? Are 
there constraints I've not thought of? Are there features that we need to 
deal with that I haven't mentioned above? Are there use cases that we 
should just abandon that could simplify the solution drastically?

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

Received on Wednesday, 28 November 2012 00:31:25 UTC