- From: Ashley Sheridan <ash@ashleysheridan.co.uk>
- Date: Wed, 28 Nov 2012 22:50:28 +0000
- To: Fred Andrews <fredandw@live.com>,"whatwg@whatwg.org" <whatwg@whatwg.org>
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@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@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. >`._.-(,_..'--(,_..'`-.;.' > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Received on Wednesday, 28 November 2012 22:58:13 UTC