Re: [whatwg] Menus and Toolbars
On 12/04/2012 09:27 PM, Ian Hickson wrote: On Thu, 29 Nov 2012, Olli Pettay wrote: I think we need to keep the contextmenu functionality, and I don't see reasons to not to do it the way Gecko has it now (using and ). Do you mean as opposed to allowing to refer to commands declared elsewhere in the spec? I'm not against elements. The main advantage of command="" is that it allows a context menu (or toolbar menu, or anything else if we start adding command="" to other elements like or something) to define a command in one place, and then refer to it other places, so that an author can e.g. disable it in one place and have all the UI update. I think that's pretty useful. Is this not something Gecko will implement? (It's based on XUL...) I'm also still hoping from input from Safari, Opera, and IE regarding what kinds of stuff would be acceptable to implement here. type=button might be nice. Some feedback that was raised on IRC was that it might make more sense to have a that, when clicked, shows the contextmenu="". Or a that uses the designated menu. Or Label ... or some such. Yup, some form of these might be ok. Need to just remember that the contents of are handled differently in different engines. Some pass the events through , but others honor the old spec where events aren't supposed to go to child elements of The idea being that it's easier to style a to work like a menu button than to style the element itself, since you really want the element to be styled as part of being the actual menu part. In Gecko MenuItem inherits Command, so it has type, label, icon etc. We could merge those two interfaces. The spec has no Command interface. Do you mean HTMLCommandElement, or the command* attributes on HTMLElement? I mean HTMLCommandElement. But if we keep the merge obviously shouldn't happen.
Re: [whatwg] Menus and Toolbars
On Thu, 29 Nov 2012, Olli Pettay wrote: > > I think we need to keep the contextmenu functionality, and I don't see > reasons to not to do it the way Gecko has it now (using type="context"> and ). Do you mean as opposed to allowing to refer to commands declared elsewhere in the spec? The main advantage of command="" is that it allows a context menu (or toolbar menu, or anything else if we start adding command="" to other elements like or something) to define a command in one place, and then refer to it other places, so that an author can e.g. disable it in one place and have all the UI update. I think that's pretty useful. Is this not something Gecko will implement? (It's based on XUL...) I'm also still hoping from input from Safari, Opera, and IE regarding what kinds of stuff would be acceptable to implement here. > type=button might be nice. Some feedback that was raised on IRC was that it might make more sense to have a that, when clicked, shows the contextmenu="". Or a that uses the designated menu. Or Label ... or some such. The idea being that it's easier to style a to work like a menu button than to style the element itself, since you really want the element to be styled as part of being the actual menu part. > In Gecko MenuItem inherits Command, so it has type, label, icon etc. We > could merge those two interfaces. The spec has no Command interface. Do you mean HTMLCommandElement, or the command* attributes on HTMLElement? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Menus and Toolbars
Hi, I like the 2nd proposal, but #3 would be ok too in my opinion Jan On Wed, Nov 28, 2012 at 1:12 AM, Ian Hickson wrote: > > (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 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 elements in your > markup and they automatically get turned into menu items. > > There's also a generic element for when you don't need an > existing element to be used. Firefox essentially only implements this, > though it's called in Firefox. also supports an > attribute that points at other elements to indirectly define features. > > > To move forward on this, here are some proposals: > > #1: Drop 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 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 . > > The element in "context" and "button" modes would only have three > elements as descendants: elements, elements, and > elements. (Or maybe no s, and we do separators by using groups of > elements without labels.) Other children are ignored. > > 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 , 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 , and if so > how, especially given high-res screens, but that's a minor detail.) > > With type=button, CSS would apply to the and elements, > maybe with a limited set of properties applying. Long term, we look to XBL > or Web components or whatever for styling. > > We drop entirely. > > > #2a: Same as #2, except we keep as a way to introduce commands > without using existing elements. > > > #3: We forget the non-JS case; so, the same as #2, but doesn't > get a command="" attribute. We add radio menu items, checkbox menu items, > and the like, over time, as features on . (Defined much like > 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. `
Re: [whatwg] Menus and Toolbars
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 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 + >> From: i...@hixie.ch >> To: wha...@whatwg.org >> CC: jackalm...@gmail.com; dglaz...@chromium.org; tk...@chromium.org; >rn...@webkit.org; eocon...@apple.com; koivi...@iki.fi; >jan.va...@gmail.com; ad...@apple.com; jon...@apple.com; >sim...@opera.com; hsivo...@iki.fi; jgra...@opera.com; >mou...@lamouri.fr; jo...@sicking.cc; o...@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 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 elements in >your >> markup and they automatically get turned into menu items. >> >> There's also a generic element for when you don't need an >> existing element to be used. Firefox essentially only implements >this, >> though it's called in Firefox. also supports an >> attribute that points at other elements to indirectly define >features. >> >> >> To move forward on this, here are some proposals: >> >> #1: Drop 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 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 . >> >> The element in "context" and "button" modes would only have >three >> elements as descendan
Re: [whatwg] Menus and Toolbars
On Tue, Nov 27, 2012 at 4:12 PM, Ian Hickson wrote: > To move forward on this, here are some proposals: > > #1: Drop 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 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 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 . > > The element in "context" and "button" modes would only have three > elements as descendants: elements, elements, and > elements. (Or maybe no s, and we do separators by using groups of > elements without labels.) Other children are ignored. > > 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 , 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 , and if so > how, especially given high-res screens, but that's a minor detail.) > > With type=button, CSS would apply to the and elements, > maybe with a limited set of properties applying. Long term, we look to XBL > or Web components or whatever for styling. > > We drop entirely. > > > #2a: Same as #2, except we keep 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 element? (Thus delegating the actual "toolbar" styling fully to CSS.) > #3: We forget the non-JS case; so, the same as #2, but doesn't > get a command="" attribute. We add radio menu items, checkbox menu items, > and the like, over time, as features on . (Defined much like > 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
Re: [whatwg] Menus and Toolbars
Greetings, I'm not a browser implementor, but I have been dealing quite a bit with menus and other GUI stuff from the web development perspective; so here it goes some comments I hope implementors might find interesting: I have put a first example on http://std.dragon-tech.org/mainmenu.png All you can see there is doable with plain CSS and HTML. It doesn't even use any CSS3 features. In fact, the whole thing works fine in IE8. As Fred Andrews mentioned, menus are quite easy to achieve with no scripting, as long as one stays within "hover-based" menus. Of course, most of the buttons and items in the screenshot require JS to actually do anything, but that's because of the app's own complexity. All the stuff in that window should be pretty much accessible (everything in there are ul's, li's, and img's with matching @alt and @title for the toolbar, which contains only shortcuts anyway, and load's of @onclick attributes that could be easily replaced by 's with @href's on a more "web-ish" scenario). In summary, menu bars and tool bars are quite a solved problem Now, here is when stuff gets serious: http://std.dragon-tech.org/contextmenu.png To be honest, I hate most of the code behind that with a passion... and I wrote it! I get paid for making stuff work, and thus I make stuff work, no matter what it takes. The context menu requires JS to display at all. It "overrides" the browser's native menu (which sometimes would be useful). There is a huge, empty, transparent div covering the whole iframe (the main area on the screen with the table on it) just so it can catch clicks and dismiss the menu. The "context menu key" (that nice thing between right Ctrl and the "Windows" key) doesn't do anything (doesn't trigger neither my menu nor the browser's) when the iframe has focus. Don't get me wrong, I quite love what I pulled off, and so do most of the app's users; but I loathe the truckload of crap code I have to feed the browser for everything to work as intended. So, in summary, context menus are somewhat achievable with significant scripting, some creativity, and epic x-browser patience; but it's still a problem far from solved. As a web developer, what I'd love to see implemented natively would be: * A mechanism (most probably an attribute + a CSS pseudo-class, or maybe even recycling :hover) to show click-based menu bars some script-less love. * A mechanism to deal with context menus in a sane way. It all boils down to UA's natively handling the showing and dismissing of the menus; and maybe enabling a mechanism to define a default (did you noticed the bolded option at the start of the menu on the screenshot? Yay, double-clicking instead of right-clicking does invoke it, skipping the whole "show the menu" step! ). That would cause it to work with any native method the browser or platform already supports for displaying context menus. As a user, I would hope any context menu implementation grants me the ultimate control on which menu is used (native vs. app-provided). Of course, other users, authors, and developers may have other needs, but I can only talk about the ones that I know about. Re-capping, my needs could be solved with this (element and attribute names are meant to be verbose and descriptive, not practical nor "final"): - A @enable-toggling-hover-state-by-clicking attribute. - A or similar element, plus a mechanism to "bind" it to other elements on the page. As long as the browser deals with show/dismiss logics, I could handle everything else. If it had a @default-action attribute that would be great, but I could live without it (or, more likely, toss in a @data-* attribute, and loop through elements bound to the menu to hack in the double-click handlers). Regards, Eduard Pascual On 28 November 2012 01:12, Ian Hickson wrote: > > (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 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 impleme
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 + > From: i...@hixie.ch > To: wha...@whatwg.org > CC: jackalm...@gmail.com; dglaz...@chromium.org; tk...@chromium.org; > rn...@webkit.org; eocon...@apple.com; koivi...@iki.fi; jan.va...@gmail.com; > ad...@apple.com; jon...@apple.com; sim...@opera.com; hsivo...@iki.fi; > jgra...@opera.com; mou...@lamouri.fr; jo...@sicking.cc; o...@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 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 elements in your > markup and they automatically get turned into menu items. > > There's also a generic element for when you don't need an > existing element to be used. Firefox essentially only implements this, > though it's called in Firefox. also supports an > attribute that points at other elements to indirectly define features. > > > To move forward on this, here are some proposals: > > #1: Drop 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 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 . > > The element in "context" and "button" modes would only have three > elements as descendants: elements, elements, and > elements. (Or maybe no s, and we do separators by using groups of > elements without labels.) Other children are ignored. > > 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 , 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
[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 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 elements in your markup and they automatically get turned into menu items. There's also a generic element for when you don't need an existing element to be used. Firefox essentially only implements this, though it's called in Firefox. also supports an attribute that points at other elements to indirectly define features. To move forward on this, here are some proposals: #1: Drop 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 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 . The element in "context" and "button" modes would only have three elements as descendants: elements, elements, and elements. (Or maybe no s, and we do separators by using groups of elements without labels.) Other children are ignored. 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 , 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 , and if so how, especially given high-res screens, but that's a minor detail.) With type=button, CSS would apply to the and elements, maybe with a limited set of properties applying. Long term, we look to XBL or Web components or whatever for styling. We drop entirely. #2a: Same as #2, except we keep as a way to introduce commands without using existing elements. #3: We forget the non-JS case; so, the same as #2, but doesn't get a command="" attribute. We add radio menu items, checkbox menu items, and the like, over time, as features on . (Defined much like 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. `._.-(,_..'--(,_..'`-.;.'
