- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 28 Nov 2012 00:12:08 +0000 (UTC)
- To: whatwg@whatwg.org
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, dglazkov@chromium.org, tkent@chromium.org, rniwa@webkit.org, eoconnor@apple.com, koivisto@iki.fi, jan.varga@gmail.com, adele@apple.com, jonlee@apple.com, Simon Pieters <simonp@opera.com>, Henri Sivonen <hsivonen@iki.fi>, jgraham@opera.com, mounir@lamouri.fr, jonas@sicking.cc, ojan@chromium.org
(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