[whatwg] Menus and Toolbars
ian at hixie.ch
Tue Nov 27 16:12:08 PST 2012
(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
* menu buttons
Right now it's not implemented by anyone, though Firefox has a variant.
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).
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg