[whatwg] Menus and Toolbars

[Ashley Sheridan]

There is a hack that allows css to handle clicks using hidden checkboxes and adjacent :checked siblings. Its not terribly suited for menu-type behavior though.

Fred Andrews <fredandw at live.com> wrote:

>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 at hixie.ch
>> To: whatwg at whatwg.org
>> CC: jackalmage at gmail.com; dglazkov at chromium.org; tkent at chromium.org;
>rniwa at webkit.org; eoconnor at apple.com; koivisto at iki.fi;
>jan.varga at gmail.com; adele at apple.com; jonlee at apple.com;
>simonp at opera.com; hsivonen at iki.fi; jgraham at opera.com;
>mounir at lamouri.fr; jonas at sicking.cc; ojan at 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.  
>`._.-(,_..'--(,_..'`-.;.'
> 		 	   		  

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.