[whatwg] Menus and Toolbars

Ian Hickson ian at hixie.ch
Tue Dec 4 11:27:46 PST 2012


On Thu, 29 Nov 2012, Olli Pettay wrote:
> 
> I think we need to keep the contextmenu functionality, and I don't see 
> reasons to not to do it the way Gecko has it now (using <menu 
> type="context"> and <menuitem>).

Do you mean as opposed to allowing <menuitem> to refer to commands 
declared elsewhere in the spec?

The main advantage of command="" is that it allows a context menu (or 
toolbar menu, or anything else if we start adding command="" to other 
elements like <button> or something) to define a command in one place, and 
then refer to it other places, so that an author can e.g. disable it in 
one place and have all the UI update.

I think that's pretty useful. Is this not something Gecko will implement? 
(It's based on XUL...)

I'm also still hoping from input from Safari, Opera, and IE regarding what 
kinds of stuff would be acceptable to implement here.


> type=button might be nice.

Some feedback that was raised on IRC was that it might make more sense to 
have a <button type=menu> that, when clicked, shows the contextmenu="". Or 
a <button type=menu menu=...> that uses the designated menu. Or <button 
type=menu> Label <menu type=context>...</menu> </button> or some such.

The idea being that it's easier to style a <button> to work like a menu 
button than to style the <menu> element itself, since you really want the 
<menu> element to be styled as part of being the actual menu part.


> In Gecko MenuItem inherits Command, so it has type, label, icon etc. We 
> could merge those two interfaces.

The spec has no Command interface. Do you mean HTMLCommandElement, or the 
command* attributes on HTMLElement?

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


More information about the whatwg mailing list