Re: [whatwg] menu and friends
On Wed, Jul 24, 2013 at 12:45 AM, Ian Hickson i...@hixie.ch wrote: If the options are: - authors never use the feature - users lose their control over their browser - the feature has a complicated API ...then we're stuck in a bad place, certainly. But I don't think those are the only options; what about these, for instance: - authors use the feature anyway, and like that it gives users power - browsers default to showing mainly the author's menuitems, but offer a discoverable way for users to find more options if they need them Ok, the first of these two might be too optimistic, but the second should be workable, no? That's what the spec now suggests. I've added an example that shows how this could work: Before (only the author's commands): http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-collapsed.png After (the user having clicked a disclosure widget): http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-expanded.png I like it, it's a good compromise. Jan
Re: [whatwg] menu and friends
On Mon, 31 Dec 2012, Jonas Sicking wrote: On Fri, Dec 28, 2012 at 11:07 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 28 Dec 2012, Jonas Sicking wrote: I don't think it's a good solution to leave it undefined if all/none/some of the UA menuitems are displayed by default. While it on an API level won't break anything, authors consider as breaking a lot more things than APIs not behaving as expected. I'm happy to give guidance that happens to match what the browser vendors want to do anyway, but I don't think it makes sense to make a page- undetectable UI detail like this a conformance requirement. I agree that defining exact UI is a bad idea. However I think we should define the semantic meaning of the context menu. If the semantics are that the context menu provided by the page is intended to be additional context actions, or alternative context actions. I've tried to add more text to the spec to encourage UAs to not show the UA menu items as prominently. Is that sufficient? We're constrained in what we can do, given that this is UI stuff. So are you proposing that the default should be that no UA menu options are displayed. I.e. the default being as if nodefault was set? As a user, I would hate that. But if you as a browser vendor are telling me as a spec writer that this is what would be needed to convince authors to not use divs for context menus, then yes. What I was saying as a browser vendor is that I don't think that authors are going to use this feature unless it provide the ability to replace the existing context menu. Or at least almost entirely replace it. Sure. Honestly, though, I think the bigger blocker right now is that there's only one implementation (and it doesn't match the spec). You are the one that is requesting that we only have a single mode. Well, I think in general it's pretty uncontroversial that, all other things being equal, APIs are better if they have less surface area. So sure, I'd rather we not have multiple modes if we don't need them. If we are to fulfill both these requirements then yes, we end up with something that both you and I would hate in many cases. The alternative that I have proposed, but that you so far have rejected, is the ability for the author to select mode, i.e. select if he/she wants to replace or add to the existing menu. If the options are: - authors never use the feature - users lose their control over their browser - the feature has a complicated API ...then we're stuck in a bad place, certainly. But I don't think those are the only options; what about these, for instance: - authors use the feature anyway, and like that it gives users power - browsers default to showing mainly the author's menuitems, but offer a discoverable way for users to find more options if they need them Ok, the first of these two might be too optimistic, but the second should be workable, no? That's what the spec now suggests. I've added an example that shows how this could work: Before (only the author's commands): http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-collapsed.png After (the user having clicked a disclosure widget): http://www.whatwg.org/specs/web-apps/current-work/images/contextmenu-expanded.png As a user, what I would like to be the behaviour, without the ability for the author to override it, is for the context menu to have the author's context menu items plus the context-sensitive items that cannot be accessed via the regular menus (e.g. Inspect Element, View Image, Copy Link Location, that kind of thing). The ability to override the authors request of replacing the context menu seems like a quality of implementation issue. For example I would imagine that Firefox would hook up the already existing allow authors to replace context menu UI option to control whether the nodefault attribute was honored. Likewise chrome could supply an extension to do the same thing. Personally, I don't want to prevent authors from providing me with features. I just want to prevent them from removing features. What I want is the union of the site's features and the browser's features. Firefox's allow authors to replace context menu UI option is IMHO insufficient. I guess I could live with that as long as there was a way for the page to opt in to displaying items. It would allow adding more finegrained control over which categories of menu items are turned backed on which could be neat. I'm very skeptical about adding any kind of control here before we have broader implementation experience. Once we do, then it will be revisited anyway, since we have this bug on file: I doubt that I can change your mind on this. But I'll note that that means that that likely means that we'll have to make the default behavior the behavior that you like less. I think it's possible to have a default behaviour that
Re: [whatwg] menu and friends
On Wed, Jan 9, 2013 at 10:17 PM, Ian Hickson i...@hixie.ch wrote: Optimising for the short-term shim author's experience rather than the long-term HTML authoring experience seems backwards to me. After input from a couple of other Gecko developers, I withdraw my objection to menuitem being void. As for command behavior in the parser, all major browsers have shipped releases with command as void, so we won't be able to reliably introduce a non-void element called command in the future anyway. Therefore, I don't see value in removing the voidness of command from parsing or serialization. The element doesn't exist, so there's no value in having it. We can easily introduce a non-void command in ten years if we need to, since by then the current parsers will be gone. Even if we accept, for the sake of the argument, that the current parsers will be gone in 10 years, it is incorrect to consider only parsers. Considering serializers is also relevant. The voidness of command has already propagated to various places—including serializer specs like http://www.w3.org/TR/xslt-xquery-serialization-30/ . (No doubt the XSLT folks will be super-happy when we tell them that the list of void elements has changed again.) At any point of the future, it is more likely that picking a new element name for a newly-minted non-void element will cause less (maybe only an epsilon less but still less) hassle than trying to re-introduce command as non-void. Why behave as if finite-length strings were in short supply? Why not treat command as a burned name just like legend and pick something different the next time you need something of the same theme when interpreted as an English word? What makes an element exist for you? Evidently, basefont and bgsound exist enough to get special parsing and serialization treatment. Is multiple interoperable parsing and serialization implementations not enough of existence and you want to see deployment in existing content, too? Did you measure the non-deployment of command on the Web or are we just assuming it hasn't been used in the wild? Even if only a few authors have put command in head, changing parsing to make command break out of head is bad. What do we really gain except for test case churn, makework in code and potential breakage from changing command as opposed to treating it as a used-up identifier and minting a new identifier in the future if a non-void element with a command-like name is needed in the future? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] menu and friends
On Sat, Dec 29, 2012 at 3:23 AM, Ian Hickson i...@hixie.ch wrote: * menuitem is void (requires parser changes). * command is entirely gone. (Actually, I renamed command to menuitem and made it so it's only allowed in menu.) Did you actually make these changes to the parsing algorithm? It seems to me that you didn't, and I'm happy that you didn't. Currently, menuitem is non-void in Firefox. It was initially designed to be void but that never shipped and the non-voidness is, AFAIK, considered intentional. For one thing, being non-void makes the element parser-neutral and, therefore, easier to polyfill in menuitem-unaware browsers. As for command behavior in the parser, all major browsers have shipped releases with command as void, so we won't be able to reliably introduce a non-void element called command in the future anyway. Therefore, I don't see value in removing the voidness of command from parsing or serialization. Could you, please, revert the serializing algorithm to treat command as void and menuitem as non-void? -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] menu and friends
On 1/4/13 7:05 PM, L. David Baron wrote: I feel that I do see this quite often. maps.google.com, Google docs, and Zimbra are three examples off the top of my head that I spend a lot of time with. Has anyone asked the authors of these sites if they would have liked to retain the browser's default context menu items if they had been able to do so (while simultaneously adding their own items)? It's certainly an interesting dichotomy. If you look at it from the PoV of a traditional browser-UI-implementer, it's an unsettling prospect... Allowing sites to override the context menu leads to undesirable user surprise (Hey, where'd my content menu stuff go?!). And in the past(?) a significant amount of oncontextmenu usage was used solely for sketchy copy-protection purposes (ie, attempting to block copy selected text or copy image location or view source). If you look at it from the PoV of a modern webapp (whatever that means), many of the browser's standard context menu entries are simply not terribly relevant to the webapp-specific uses a user might be expecting. Consider the meager overlap (even in a very fuzzy sense) between a browser's content menu and that of any native application. In broad strokes, I'd suspect that we need to allow sites to completely replace the context menu. (Specifically, for sites that implement complex applications -- like Google docs or Zimbra -- but I don't know how to tell the difference in code). I would also be quite interested in author opinions on cases where they want a subset of browser menu items (such as clipboard ops) mixed in with site-specific items. A short-term thing we (browsers) could try would be to always show some important subset of context menu items when the site is also supplying their own. But perhaps easier said than done: at least in Firefox there's a fair amount of complexity in determining what menu items to show... See http://mxr.mozilla.org/mozilla-central/source/browser/base/content/nsContextMenu.js [While I'm thinking of it, a related idea that's been bounced around in Firefox-land is having some way of granting modestly elevated permissions to a user's favorite sites. For example, if you pin a Gmail tab -- or maybe just visit it more frequently than average? -- perhaps it should be able to do a few more things than the average web page... Certainly not anything grossly sensitive w.r.t. privacy/security. But maybe it should be able to change the context menu, use more localstorage, etc. It's not something we're actively implementing, but is an interesting area to ponder.] Justin
Re: [whatwg] menu and friends
On Sat, Dec 29, 2012 at 10:17 AM, David Young dyo...@pobox.com wrote: On Sat, Dec 29, 2012 at 01:23:20AM +, Ian Hickson wrote: On Sun, 23 Oct 2011, Eric Sh. wrote: I was trying out the HTML5 context menu in firefox and I saw that there is no way(in the specs) to create an empty menu with only selected context menu items in it. So for example if I have an image element and I want to create a context menu with the items: Rotate and Share - I have to ask the browser to Add them to the regular context menu along with the ten other items that are already there. This makes a bulky context menu when I only need those two items and it is especially hurtful for user experience if the context menu is close to the bottom of the screen and is moved above the mouse cursor. I suggest adding a way to ask the browser to create a brand new context menu with only those items. Not showing the browser's own context menu items is a hurtful user experience as well; indeed, possibly a worse one. I agree that it's an awful experience, especially because it turns the user's habits against them. If the Nth item in the menu is ordinarily the UA's Copy Link Location and an app removes or re-orders items so that the Nth item changes to Rotate, Share, or Delete, then users are in for a surprise when they make the automatic Copy Link Location gesture. Gah, strongly agree. Simple example - I use Back constantly in the context menu, and would be really pissed if pages could easily kill that. I already get angry when I accidentally right-click a link and just select the first option without looking closely. On Mon, Dec 31, 2012 at 12:54 AM, Jonas Sicking jo...@sicking.cc wrote: What I was saying as a browser vendor is that I don't think that authors are going to use this feature unless it provide the ability to replace the existing context menu. Or at least almost entirely replace it. I don't think I can agree with this. This argument would be more believable if authors currently used pile-of-divs for context menus a lot, but I only rarely actually see it. I think this is because it's just plain *hard* to do it even half-decently. The extreme ease with which authors will be able to create high-quality context menus with menu will, I think, override a lot of the concerns. That said, I've got no problem with something like move all of the normal options to a submenu that's the first item in the menu. ~TJ
Re: [whatwg] menu and friends
On Fri, Jan 4, 2013 at 3:34 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Sat, Dec 29, 2012 at 10:17 AM, David Young dyo...@pobox.com wrote: On Sat, Dec 29, 2012 at 01:23:20AM +, Ian Hickson wrote: On Sun, 23 Oct 2011, Eric Sh. wrote: I was trying out the HTML5 context menu in firefox and I saw that there is no way(in the specs) to create an empty menu with only selected context menu items in it. So for example if I have an image element and I want to create a context menu with the items: Rotate and Share - I have to ask the browser to Add them to the regular context menu along with the ten other items that are already there. This makes a bulky context menu when I only need those two items and it is especially hurtful for user experience if the context menu is close to the bottom of the screen and is moved above the mouse cursor. I suggest adding a way to ask the browser to create a brand new context menu with only those items. Not showing the browser's own context menu items is a hurtful user experience as well; indeed, possibly a worse one. I agree that it's an awful experience, especially because it turns the user's habits against them. If the Nth item in the menu is ordinarily the UA's Copy Link Location and an app removes or re-orders items so that the Nth item changes to Rotate, Share, or Delete, then users are in for a surprise when they make the automatic Copy Link Location gesture. Gah, strongly agree. Simple example - I use Back constantly in the context menu, and would be really pissed if pages could easily kill that. I already get angry when I accidentally right-click a link and just select the first option without looking closely. Can you elaborate on what you mean by if above. It's already the case that pages can in all popular browsers. Please note that none of the proposals here remove that option. Not even the proposal from Ian. On Mon, Dec 31, 2012 at 12:54 AM, Jonas Sicking jo...@sicking.cc wrote: What I was saying as a browser vendor is that I don't think that authors are going to use this feature unless it provide the ability to replace the existing context menu. Or at least almost entirely replace it. I don't think I can agree with this. This argument would be more believable if authors currently used pile-of-divs for context menus a lot, but I only rarely actually see it. I think this is because it's just plain *hard* to do it even half-decently. The extreme ease with which authors will be able to create high-quality context menus with menu will, I think, override a lot of the concerns. I feel that I do see this quite often. maps.google.com, Google docs, and Zimbra are three examples off the top of my head that I spend a lot of time with. I agree that the number of sites is relatively small. But for app like sites, which I think people are spending more and more time in as more things migrate to the web, it's not uncommon. That said, I've got no problem with something like move all of the normal options to a submenu that's the first item in the menu. Cool. / Jonas
Re: [whatwg] menu and friends
On Fri, Jan 4, 2013 at 4:56 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Jan 2013, Jonas Sicking wrote: Gah, strongly agree. Simple example - I use Back constantly in the context menu, and would be really pissed if pages could easily kill that. [...] Can you elaborate on what you mean by if above. It's already the case that pages can in all popular browsers. Please note that none of the proposals here remove that option. Not even the proposal from Ian. The spec allows the browser to remove that option. (User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus) It even gives an example of how to do it (For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu). Sure, but this is purely academic unless browsers actually do this. / Jonas
Re: [whatwg] menu and friends
On Fri, Jan 04, 2013 at 03:34:11PM -0800, Tab Atkins Jr. wrote: On Sat, Dec 29, 2012 at 10:17 AM, David Young dyo...@pobox.com wrote: On Sat, Dec 29, 2012 at 01:23:20AM +, Ian Hickson wrote: On Sun, 23 Oct 2011, Eric Sh. wrote: I was trying out the HTML5 context menu in firefox and I saw that there is no way(in the specs) to create an empty menu with only selected context menu items in it. So for example if I have an image element and I want to create a context menu with the items: Rotate and Share - I have to ask the browser to Add them to the regular context menu along with the ten other items that are already there. This makes a bulky context menu when I only need those two items and it is especially hurtful for user experience if the context menu is close to the bottom of the screen and is moved above the mouse cursor. I suggest adding a way to ask the browser to create a brand new context menu with only those items. Not showing the browser's own context menu items is a hurtful user experience as well; indeed, possibly a worse one. I agree that it's an awful experience, especially because it turns the user's habits against them. If the Nth item in the menu is ordinarily the UA's Copy Link Location and an app removes or re-orders items so that the Nth item changes to Rotate, Share, or Delete, then users are in for a surprise when they make the automatic Copy Link Location gesture. Gah, strongly agree. Simple example - I use Back constantly in the context menu, and would be really pissed if pages could easily kill that. I already get angry when I accidentally right-click a link and just select the first option without looking closely. Ok. You also write, That said, I've got no problem with something like move all of the normal options to a submenu that's the first item in the menu. ... which seems to contradict your strong agreement above? I.e., it's ok if the Back in the context menu moves to a context submenu? That's going to create surprising results for automatic gestures, too. Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
Re: [whatwg] menu and friends
On Friday 2013-01-04 16:52 -0800, Jonas Sicking wrote: On Fri, Jan 4, 2013 at 3:34 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Mon, Dec 31, 2012 at 12:54 AM, Jonas Sicking jo...@sicking.cc wrote: What I was saying as a browser vendor is that I don't think that authors are going to use this feature unless it provide the ability to replace the existing context menu. Or at least almost entirely replace it. I don't think I can agree with this. This argument would be more believable if authors currently used pile-of-divs for context menus a lot, but I only rarely actually see it. I think this is because it's just plain *hard* to do it even half-decently. The extreme ease with which authors will be able to create high-quality context menus with menu will, I think, override a lot of the concerns. I feel that I do see this quite often. maps.google.com, Google docs, and Zimbra are three examples off the top of my head that I spend a lot of time with. Has anyone asked the authors of these sites if they would have liked to retain the browser's default context menu items if they had been able to do so (while simultaneously adding their own items)? -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂
Re: [whatwg] menu and friends
On Fri, 4 Jan 2013, Jonas Sicking wrote: On Fri, Jan 4, 2013 at 4:56 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Jan 2013, Jonas Sicking wrote: Gah, strongly agree. Simple example - I use Back constantly in the context menu, and would be really pissed if pages could easily kill that. [...] Can you elaborate on what you mean by if above. It's already the case that pages can in all popular browsers. Please note that none of the proposals here remove that option. Not even the proposal from Ian. The spec allows the browser to remove that option. (User agents may provide means for bypassing the context menu processing model, ensuring that the user can always access the UA's default context menus) It even gives an example of how to do it (For example, the user agent could handle right-clicks that have the Shift key depressed in such a way that it does not fire the contextmenu event and instead always shows the default context menu). Sure, but this is purely academic-- I was just disagreeing with the statement Not even the proposal from Ian. unless browsers actually do this. Firefox does, though its interface for it is somewhat arcane (about:config tweaking), right? Anyway, I don't really understand what we're arguing here. It's not generally controversial that we should take care in adding new features. For this one, we have one browser that implements something somewhat like what the spec now has, and that's it. We have a concern (that some browsers will avoid the feature entirely if the UA shows the items in addition to the default items), but we don't have much data to support this, and we have no data exploring whether any of the various mitigating ideas (submenu, only including critical UA items, shift key to show the original menu, never showing the original menu) satisfy authors or users sufficiently to avoid having to add more syntax. Until we have more data, not doing anything in the spec is the right move. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] menu and friends
On Fri, Dec 28, 2012 at 11:07 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 28 Dec 2012, Jonas Sicking wrote: I don't think it's a good solution to leave it undefined if all/none/some of the UA menuitems are displayed by default. While it on an API level won't break anything, authors consider as breaking a lot more things than APIs not behaving as expected. I'm happy to give guidance that happens to match what the browser vendors want to do anyway, but I don't think it makes sense to make a page- undetectable UI detail like this a conformance requirement. I agree that defining exact UI is a bad idea. However I think we should define the semantic meaning of the context menu. If the semantics are that the context menu provided by the page is intended to be additional context actions, or alternative context actions. So are you proposing that the default should be that no UA menu options are displayed. I.e. the default being as if nodefault was set? As a user, I would hate that. But if you as a browser vendor are telling me as a spec writer that this is what would be needed to convince authors to not use divs for context menus, then yes. What I was saying as a browser vendor is that I don't think that authors are going to use this feature unless it provide the ability to replace the existing context menu. Or at least almost entirely replace it. You are the one that is requesting that we only have a single mode. If we are to fulfill both these requirements then yes, we end up with something that both you and I would hate in many cases. The alternative that I have proposed, but that you so far have rejected, is the ability for the author to select mode, i.e. select if he/she wants to replace or add to the existing menu. What the default mode should be I care less about. But I would note that using as default whatever we think is the more user friendly option is likely a good idea. As a user, what I would like to be the behaviour, without the ability for the author to override it, is for the context menu to have the author's context menu items plus the context-sensitive items that cannot be accessed via the regular menus (e.g. Inspect Element, View Image, Copy Link Location, that kind of thing). The ability to override the authors request of replacing the context menu seems like a quality of implementation issue. For example I would imagine that Firefox would hook up the already existing allow authors to replace context menu UI option to control whether the nodefault attribute was honored. Likewise chrome could supply an extension to do the same thing. I guess I could live with that as long as there was a way for the page to opt in to displaying items. It would allow adding more finegrained control over which categories of menu items are turned backed on which could be neat. I'm very skeptical about adding any kind of control here before we have broader implementation experience. Once we do, then it will be revisited anyway, since we have this bug on file: I doubt that I can change your mind on this. But I'll note that that means that that likely means that we'll have to make the default behavior the behavior that you like less. Note that I didn't say always but many cases. I do think it's the case that in many cases displaying the UA menuitems is desirable. A good example of this is menu items that control access to the clipboard since that's something that webpages can't implement themselves. Most browsers do not permit reading and writing to the clipboard arbitrarily. Aren't those items accessible from the main menu? Yes, though I think they are used commonly enough from the context menu that it'd bother users a lot if we removed it from the context menu of editable text. What items are there that it sometimes makes sense to expose but othertimes does not make sense to expose? I'm not sure I understand the question. / Jonas
Re: [whatwg] menu and friends
On Sat, Dec 29, 2012 at 01:23:20AM +, Ian Hickson wrote: On Sun, 23 Oct 2011, Eric Sh. wrote: I was trying out the HTML5 context menu in firefox and I saw that there is no way(in the specs) to create an empty menu with only selected context menu items in it. So for example if I have an image element and I want to create a context menu with the items: Rotate and Share - I have to ask the browser to Add them to the regular context menu along with the ten other items that are already there. This makes a bulky context menu when I only need those two items and it is especially hurtful for user experience if the context menu is close to the bottom of the screen and is moved above the mouse cursor. I suggest adding a way to ask the browser to create a brand new context menu with only those items. Not showing the browser's own context menu items is a hurtful user experience as well; indeed, possibly a worse one. I agree that it's an awful experience, especially because it turns the user's habits against them. If the Nth item in the menu is ordinarily the UA's Copy Link Location and an app removes or re-orders items so that the Nth item changes to Rotate, Share, or Delete, then users are in for a surprise when they make the automatic Copy Link Location gesture. However, the spec does allow the user agent to not add its own items if that is considered better. Browsers are encouraged to provide an override if they do that (e.g. shift-click brings up the full menu). I think this is a step in the right direction, however, it also works against automaticity. Say that a click usually brings up the UA's context menu. In my app, however, a click brings up my app's context menu sans UA items; shift-click brings up the UA's context menu. This has the same problem as I mentioned before: in the app, my automatic gesture that starts with a click does some surprising thing instead of copying the link location. I think that good advice to the browser implementors is to either 1) reserve one gesture for the UA context menu (click), and a second gesture for the app context menu (shift-click), OR 2) always add the UA items to the context menu in consistent places, for example by adding app-specific context menu items after UA items Dave -- David Young dyo...@pobox.comUrbana, IL(217) 721-9981
[whatwg] menu and friends
I've just checked in a somewhat large redesign of how context menus work in HTML. It's much more similar, though not identical, to what Firefox implements. It drops the command element, adds a menuitem element, introduces a button type=menu feature, and drops menu type=toolbar. High-level overview: * There's now three features of relevance here: 1. Toolbars. 2. Context menus. 3. Pop-up menu buttons. * Toolbars are nothing more than a div with the element name menu. There's no magic at all, no special content model, it's all CSS for styling, you use regular form controls to fill the toolbar. * Context menus and pop-up menu button menus use menu type=popup. The only children allowed for these elements are menuitem, hr for separators, and menu label= for submenus. * menu type=menu menu=id menu type=popup id=id defines a pop-up menu button. * menuitem has all the stuff that command used to have, including menuitem command=foo to point to another element (e.g. an a href, button, option, etc) and accesskey=. * menuitem is void (requires parser changes). * command is entirely gone. (Actually, I renamed command to menuitem and made it so it's only allowed in menu.) I would love input from implementors regarding whether this is something they are more interested in implementing than what came before. On Wed, 28 Nov 2012, Ian Hickson wrote: 1. Styling of toolbars and menu buttons is just not defined. Toolbars could be a purely stylistic issue, to be solved either exclusively by CSS, or CSS plus a component/widget binding model (whatever solution we end up with for that). I've made the type=toolbar state be a regular div-like context. Authors are on their own again for making toolbars for now. 2. Nobody is implementing it, in particular, the algorithm that converts HTML elements into a menu structure seems unpopular. I've dramatically simplified this algorithm. It now only consists of menu, menuitem, and hr. (We can drop hr if people don't like that; it's actually redundant with the handling of menu without a label.) 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. I haven't got a solution for drop-down button styling. The menu in this scenario is display:none, so I can't get any styles out of it to affect the styling of the drop-down menu. I'm open to suggestions for how to fix this; maybe the solution is to have something like: display: compute-style-but-do-not-render-anything-in-flow On Wed, 28 Nov 2012, Eduard Pascual wrote: 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 a's with @href's on a more web-ish scenario). In summary, menu bars and tool bars are quite a solved problem I don't think a pile of CSS should be needed for this, though, that's the problem. Let alone any JS: 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. Ideally you should just have to describe your toolbar or context menu in HTML and be done with it. * 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. Traditional menu _bars_ are not something that I've solved with this update (specifically, the part where you click on one menu bar's label and then hover over to
Re: [whatwg] menu and friends
On Fri, Dec 28, 2012 at 5:23 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 22 Oct 2011, Jonas Sicking wrote: I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=12999 on this a while ago. So far no changes to the spec though. I'm not sure I really agree with the premise of the bug. It points to this image as a reason for not showing UA context menu items: http://userexperience.evantageconsulting.com/wp-content/uploads/2010/08/html5-context-menu.png ...but that to me is a perfect example of why this is a misfeature. Where's Inspect Element, for example? I think it would make sense for browsers to skip the less important menu items (those that are accessible via the menus, for instance) when showing a context menu that the author is providing. (But then, I think it would make sense to not show those ever.) But for things that are only sanely accessible via the context menu, I don't see why we'd drop them. I would mostly agree with your reasoning here if it weren't for the fact that all UAs by default already allow webpages to hide the context menu of any part of the page. As long as that remains the case we are giving authors two options: A) Use pile of divs to render context menu and get full control over what is rendered in the context menu. B) Use menu to create a more accessible menu, but accept that they will always be listed together with a list of UA items. There's also the following facts to take into account: * As far as I know, no UA has expressed willingness to drop the ability to hide UA context menus. I.e. there is no indication that the above two options will change. * Authors tend to prioritize control of UX over platform integration and accessibility. * more options isn't always equivalent to better UX. I.e. even a website that has the intent and knowledge to design the, for the user, perfect UX would hide many or all of the built-in menu items in many cases. All of this makes me think that in very many cases authors will choose option A above. We need to remember that convincing UAs to implement this feature is just the first step here. Convincing authors to use it is the second. Additionally, the nodefault attribute proposed in [1] can be treated by the UA as a hint without risking pages breaking. For example it could choose to hide only non-critical menu items. Or hide none of them but move them into a sub-menu. While mean that authors still wouldn't have 100% control over the UX, they would have dramatically more control than as the proposal stands now, heavily tipping the scale towards option B. The pile of divs mechanism that websites use today doesn't permit any of the control that [1] permits since ignoring the contextmenu attribute in many cases effectively breaks websites. And it certainly doesn't permit combining website menuitems with UA menuitems. [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=12999 / Jonas
Re: [whatwg] menu and friends
(Oops, in my earlier message I cc'ed people instead of bcc'ing them, and this means reply-to-all replies are going to get caught in the mailing list software's filters. If you reply to this thread, please don't forget to strip the cc list down to nothing or only one or two people. If you forget, let me know that I should go unstick your e-mail from the mailing list filters.) On Fri, 28 Dec 2012, Jonas Sicking wrote: I think it would make sense for browsers to skip the less important menu items (those that are accessible via the menus, for instance) when showing a context menu that the author is providing. (But then, I think it would make sense to not show those ever.) But for things that are only sanely accessible via the context menu, I don't see why we'd drop them. I would mostly agree with your reasoning here if it weren't for the fact that all UAs by default already allow webpages to hide the context menu of any part of the page. Yes, I don't understand why browsers do this. It drives me crazy, as a user. As long as that remains the case we are giving authors two options: A) Use pile of divs to render context menu and get full control over what is rendered in the context menu. B) Use menu to create a more accessible menu, but accept that they will always be listed together with a list of UA items. Browsers don't _have_ to show their items with the contextmenu= menu. If the two choices above are the only choices, then it seems to me that browsers should just not include their menu in the contextmenu= menu. * more options isn't always equivalent to better UX. I.e. even a website that has the intent and knowledge to design the, for the user, perfect UX would hide many or all of the built-in menu items in many cases. Right, this is why I suggested that the UA should drop all non-context- specific items when there's a page context menu. So e.g. for Firefox, in the default (context menu on body) case, keep Inspect Element and View Background Image, but drop everything else. All of this makes me think that in very many cases authors will choose option A above. In that case, when would it make sense for the browser to ever include the default menu items? i.e. why not make nodefault the default? Additionally, the nodefault attribute proposed in [1] can be treated by the UA as a hint without risking pages breaking. For example it could choose to hide only non-critical menu items. Or hide none of them but move them into a sub-menu. Why not do this anyway, always, and forego the attribute? While mean that authors still wouldn't have 100% control over the UX, they would have dramatically more control than as the proposal stands now, heavily tipping the scale towards option B. The proposal as it stands now is that the browsers can show only the page's context menu, only the user agent's context menu, or anything in between. I don't think it's heavily tipped in either direction. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] menu and friends
On Fri, Dec 28, 2012 at 8:45 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 28 Dec 2012, Jonas Sicking wrote: [rearranging the thread a bit here] While mean that authors still wouldn't have 100% control over the UX, they would have dramatically more control than as the proposal stands now, heavily tipping the scale towards option B. The proposal as it stands now is that the browsers can show only the page's context menu, only the user agent's context menu, or anything in between. I don't think it's heavily tipped in either direction. I don't think it's a good solution to leave it undefined if all/none/some of the UA menuitems are displayed by default. While it on an API level won't break anything, authors consider as breaking a lot more things than APIs not behaving as expected. I.e. if some UAs are rendering all items by default and some render none, that will mean that authors will consider the feature broken in some UAs. It'll also mean that authors are having the same lack of control as I talked about meaning that the incentives are for option A still. As long as that remains the case we are giving authors two options: A) Use pile of divs to render context menu and get full control over what is rendered in the context menu. B) Use menu to create a more accessible menu, but accept that they will always be listed together with a list of UA items. Browsers don't _have_ to show their items with the contextmenu= menu. If the two choices above are the only choices, then it seems to me that browsers should just not include their menu in the contextmenu= menu. So are you proposing that the default should be that no UA menu options are displayed. I.e. the default being as if nodefault was set? I guess I could live with that as long as there was a way for the page to opt in to displaying items. It would allow adding more finegrained control over which categories of menu items are turned backed on which could be neat. All of this makes me think that in very many cases authors will choose option A above. In that case, when would it make sense for the browser to ever include the default menu items? i.e. why not make nodefault the default? Note that I didn't say always but many cases. I do think it's the case that in many cases displaying the UA menuitems is desirable. A good example of this is menu items that control access to the clipboard since that's something that webpages can't implement themselves. Most browsers do not permit reading and writing to the clipboard arbitrarily. But maybe starting simple and making nodefault the default behavior might not be a bad idea. However I think it's something that should be defined by spec as to make it consistent across UAs. / Jonas
Re: [whatwg] menu and friends
On Fri, 28 Dec 2012, Jonas Sicking wrote: I don't think it's a good solution to leave it undefined if all/none/some of the UA menuitems are displayed by default. While it on an API level won't break anything, authors consider as breaking a lot more things than APIs not behaving as expected. I'm happy to give guidance that happens to match what the browser vendors want to do anyway, but I don't think it makes sense to make a page- undetectable UI detail like this a conformance requirement. So are you proposing that the default should be that no UA menu options are displayed. I.e. the default being as if nodefault was set? As a user, I would hate that. But if you as a browser vendor are telling me as a spec writer that this is what would be needed to convince authors to not use divs for context menus, then yes. As a user, what I would like to be the behaviour, without the ability for the author to override it, is for the context menu to have the author's context menu items plus the context-sensitive items that cannot be accessed via the regular menus (e.g. Inspect Element, View Image, Copy Link Location, that kind of thing). I guess I could live with that as long as there was a way for the page to opt in to displaying items. It would allow adding more finegrained control over which categories of menu items are turned backed on which could be neat. I'm very skeptical about adding any kind of control here before we have broader implementation experience. Once we do, then it will be revisited anyway, since we have this bug on file: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12999 (I regularly reopen all the bugs marked LATER and go through them again.) Note that I didn't say always but many cases. I do think it's the case that in many cases displaying the UA menuitems is desirable. A good example of this is menu items that control access to the clipboard since that's something that webpages can't implement themselves. Most browsers do not permit reading and writing to the clipboard arbitrarily. Aren't those items accessible from the main menu? What items are there that it sometimes makes sense to expose but othertimes does not make sense to expose? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
