On Tue, Nov 27, 2012 at 4:12 PM, Ian Hickson <i...@hixie.ch> wrote: > 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.
I'm gonna throw out this option. Worst case, retaining <menu> solely for its context-menu additions is necessary - this keeps being requested over and over again by authors, both of small and large apps. > #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. I assume that the "button" case is meant to still support toolbars, except that each top-level entry in the toolbar is a separate <menu> element? (Thus delegating the actual "toolbar" styling fully to CSS.) > #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? I'm down with keeping the current "do nothing" behavior, and the "context menu" behavior. I like the proposed "button with pop-up menu" behavior, as a better version of the old toolbar initiative. I have no opinion on the rest of the details, as they seem roughly equivalent. ~TJ