Re: [whatwg] Menus and Toolbars

Dear Ian,

Thank you opening a discussion about these interactive elements.  It would be disappointing to see these abandoned, for those who would like to see more interactive non-javascript content.

I would note that CSS alone is able to implement styled menus but only for 'hover to activate' and not for 'click to activate'.  Might there be an alternative approach using a 'click to toggle' property on elements that might allow CSS alone to implement click activated menus etc?

cheers
Fred

> Date: Wed, 28 Nov 2012 00:12:08 +0000
> From: ian@hixie.ch
> To: whatwg@whatwg.org
> CC: 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; simonp@opera.com; hsivonen@iki.fi; jgraham@opera.com; mounir@lamouri.fr; jonas@sicking.cc; ojan@chromium.org
> Subject: [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 12:27:51 UTC