Re: Intent to implement: Ability to surpress default contextmenu items
I would like to suggest chrome="hidden" instead of chrome="disabled". Disabled is normally related to grayed out widgets on the web () and not hidden elements (, display: none or visibility: collapse). And yes please leave some form of widget in the menu to let the user access the default menu entries even if the site have them hidden. I'm not too picky on the design for it though. // Cork - Original Me ssage - > From: "Ian Hickson" > To: "Jonas Sicking" > Cc: "Dale Harvey" , "dev-platform" > > Sent: Thursday, 10 July, 2014 6:45:14 PM > Subject: Re: Intent to implement: Ability to surpress default contextmenu > items > > On Wed, 9 Jul 2014, Jonas Sicking wrote: > > > > > > This has been suggested many times, but the reason it's not part of > > > the standard is that it's user-hostile. > > > > This argument always comes up, but I don't think this is an entirely > > accurate statement. > > > > This is less user-hostile than the web platform is today. The web > > platform today enables cancelling the contextmenu attribute which > > disables the UA context menu. > > That's why teh spec says: "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. 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." > > > > Many website use this feature to replace the UA context menu with their > > own context menu implemented in HTML. The result is a context menu which > > is less accessible. It also results in that if the user uses UA features > > to *not* make the UA context menu cancellable, then the UA context > > overlays and hides the page provided one, making it inaccessible. > > Right, that's why contextmenu="" exists in the first place. > > All I'm saying is that we should strive for the ideal middle ground, where > the page's context menu is given a strong presence, thus satisfying the > author, but where the UA actions are still easily available. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On Wed, 9 Jul 2014, Jonas Sicking wrote: > > > > This has been suggested many times, but the reason it's not part of > > the standard is that it's user-hostile. > > This argument always comes up, but I don't think this is an entirely > accurate statement. > > This is less user-hostile than the web platform is today. The web > platform today enables cancelling the contextmenu attribute which > disables the UA context menu. That's why teh spec says: "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. 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." > Many website use this feature to replace the UA context menu with their > own context menu implemented in HTML. The result is a context menu which > is less accessible. It also results in that if the user uses UA features > to *not* make the UA context menu cancellable, then the UA context > overlays and hides the page provided one, making it inaccessible. Right, that's why contextmenu="" exists in the first place. All I'm saying is that we should strive for the ideal middle ground, where the page's context menu is given a strong presence, thus satisfying the author, but where the UA actions are still easily available. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
Something like this is actually in the spec: http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus " When the user clicks the disclosure triangle, such a user agent would expand the context menu in place, to show the browser's own commands" On 10/07/14 02:11, Karl Dubost wrote: Le 10 juil. 2014 à 14:57, Jonas Sicking a écrit : Many website use this feature to replace the UA context menu with their own context menu implemented in HTML. The result is a context menu which is less accessible. It also results in that if the user uses UA features to *not* make the UA context menu cancellable, then the UA context overlays and hides the page provided one, making it inaccessible. A suggestion from the naive-poet-department: What about something where, the main contextual menu is become a child of the developer menu. Would it be an acceptable compromise? normal system: ┌ default-item 1 ├ default-item 2 └ default-item 3 When the developer creates a contextual menu ┌ dev item 1 ├ dev item 2 ├ dev item 3 └ default-sys ├ default-item 1 ├ default-item 1 └ default-item 3 so basically, it is still available but just not deployed except if the user is hovering on default-sys. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
Le 10 juil. 2014 à 14:57, Jonas Sicking a écrit : > Many website use this feature to replace the UA context menu with > their own context menu implemented in HTML. The result is a context > menu which is less accessible. It also results in that if the user > uses UA features to *not* make the UA context menu cancellable, then > the UA context overlays and hides the page provided one, making it > inaccessible. A suggestion from the naive-poet-department: What about something where, the main contextual menu is become a child of the developer menu. Would it be an acceptable compromise? normal system: ┌ default-item 1 ├ default-item 2 └ default-item 3 When the developer creates a contextual menu ┌ dev item 1 ├ dev item 2 ├ dev item 3 └ default-sys ├ default-item 1 ├ default-item 1 └ default-item 3 so basically, it is still available but just not deployed except if the user is hovering on default-sys. -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On Wed, Jul 2, 2014 at 9:14 AM, Dao wrote: > On 02.07.2014 17:30, Ehsan Akhgari wrote: >> >> On 2014-07-02, 3:12 AM, Henri Sivonen wrote: >>> >>> On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: we are looking to implement an optional attribute that allows authors to disable the default context menu items so only the applications items are shown. >>> >>> >>> I think we shouldn't do this, since it would be hostile to users. I >>> think it would be OK to allow apps to request that the User >>> Agent-provided context menu items be tucked away in a submenu, though. >> >> >> Note that this is something that web pages are already able to do. Do >> you think the contextmenu event that we currently support suffers from >> the same issue? Why is this proposal worse than that? > > > It suffers from the same issue and does indeed annoy me as a user from time > to time (e.g. with youtube's html player). However, the spec at least allows > for bypassing this behavior: > > "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. 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." We should definitely add the same language to this new feature. > Gecko supports dom.event.contextmenu.enabled to that end. It used to be a > visible preference in Firefox, but now it's merely a hidden one. And we should definitely make this pref ignore the chrome=disabled attribute. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On Mon, Jun 30, 2014 at 5:26 AM, Wesley Hardman wrote: > Suppressing the contextmenu is extremely user-hostile (for some users). > There is a reason I always run with dom.event.contextmenu.enabled set to > false. This option would continue to work and make us ignore the chrome="disabled" attribute. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On Sat, Jun 28, 2014 at 9:30 PM, Ian Hickson wrote: > On Sat, 28 Jun 2014, Dale Harvey wrote: >> >> Application developers have the ability to specify additional menuitems for >> contextmenus via >> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus >> however they are currently shown in addition to the default items, we are >> looking to implement an optional attribute that allows authors to disable >> the default context menu items so only the applications items are shown. >> This is primarily targeted for Firefox OS, I believe Jonas will be looking >> to add it to the official spec. >> >> The name / value of the attribute is under discussion >> >> >> >> >> >> looks like the most likely candidate. > > This has been suggested many times, but the reason it's not part of the > standard is that it's user-hostile. This argument always comes up, but I don't think this is an entirely accurate statement. This is less user-hostile than the web platform is today. The web platform today enables cancelling the contextmenu attribute which disables the UA context menu. Many website use this feature to replace the UA context menu with their own context menu implemented in HTML. The result is a context menu which is less accessible. It also results in that if the user uses UA features to *not* make the UA context menu cancellable, then the UA context overlays and hides the page provided one, making it inaccessible. So I do agree that this feature is user hostile. But it is much less so than what's in the spec today. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
Google docs is a very good use case, In a previous job I implemented a web based spreadsheet and we also had to implement our own contextmenu and surpress the default because of the way that it conflicts. Its a catch 22, applications will continue to hijack the default menu unless the functionality is improved, but the functionality wont improve if nobody is using it. However thinking about the use case that was presented for us on Firefox OS, I am not entirely convinced that we need to surpress the default context menu items, I think we can provide better UX that doesnt leave the user with too many + confusing options so I have asked Jonas about closing the bug that was opened to implement this. On 2 July 2014 13:30, Ehsan Akhgari wrote: > On 2014-07-02, 4:16 PM, Dao wrote: > >> On 02.07.2014 20:51, Ehsan Akhgari wrote: >> >>> We can still show the UA >>> context menu if you hold down shift like we do today though. >>> >> >> What would be the equivalent to that on Firefox OS? >> > > I don't think we have a similar way to do this in Firefox OS. > > Cheers, > Ehsan > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On 2014-07-02, 4:16 PM, Dao wrote: On 02.07.2014 20:51, Ehsan Akhgari wrote: We can still show the UA context menu if you hold down shift like we do today though. What would be the equivalent to that on Firefox OS? I don't think we have a similar way to do this in Firefox OS. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On 02.07.2014 20:51, Ehsan Akhgari wrote: We can still show the UA context menu if you hold down shift like we do today though. What would be the equivalent to that on Firefox OS? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On 2014-07-02 14:51, Ehsan Akhgari wrote: > On 2014-07-02, 2:36 PM, Wesley Hardman wrote: >> The current context menu event does suffer from the same issue. If this is >> implemented, there at least needs to be a matching >> dom.event.contextmenu.showall preference to always show all menu items. >> >> I don't think this proposal is worse, but it isn't really better. With the >> current event, I always have to hit escape when I actually DO need to get to >> a custom context menu, but I can still get to both. With this proposal, I >> have to expand to get to the UA items. > > Hmm, not sure what you mean by expanding... We can still show the UA > context menu if you hold down shift like we do today though. This seems reasonable. Though it does conflict with Element Inspector. There should always be some method of reaching the UA menu without having to change anything. By expanding, I was referring to Ian's suggestion earlier in the thread. I forgot that wasn't part of the original intent. > I would recommend that instead of letting the author prevent the user from > getting to the user's browser's commands, the browser instead simply hide > the browser commands behind a disclosure chevron, as in this example: > > http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#dom-contextmenu > > > Personally whenever I am right clicking on something, it usually to > get to a UA option; rarely do I ever use the custom options (either > way). With this proposal, my most used options are further away. > > Is it perhaps because most web pages do not have a useful custom context > menu? Would you say the same thing about, let's say, Google Docs? The > Google Docs custom context menus seem like a great use case for this to me. Mostly. Google Docs is an exception, where I *would* want this. > > Cheers, > Ehsan > >> On 2014-07-02 11:30, Ehsan Akhgari wrote: >>> On 2014-07-02, 3:12 AM, Henri Sivonen wrote: On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: > we are > looking to implement an optional attribute that allows authors to disable > the default context menu items so only the applications items are shown. I think we shouldn't do this, since it would be hostile to users. I think it would be OK to allow apps to request that the User Agent-provided context menu items be tucked away in a submenu, though. >>> >>> Note that this is something that web pages are already able to do. Do >>> you think the contextmenu event that we currently support suffers from >>> the same issue? Why is this proposal worse than that? >>> >>> Cheers, >>> Ehsan >>> >> >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform >> > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On 2014-07-02, 2:55 PM, Wesley Hardman wrote: That doesn't work if you have Element Inspector installed (https://addons.mozilla.org/en-US/firefox/addon/element-inspector/). It is restart-less, so I suppose its easy to toggle on and off. Add-ons which hijack our key bindings cause all sorts of issues, but most of our users do not have Element Inspector installed so I don't think this is a very important problem (but it would be nice to get that add-on fixed nontheless.) Cheers, Ehsan On 2014-07-02 14:49, Jan Varga wrote: Just FYI, the current implementation in Gecko also checks the shift key, if it is pressed then custom context menu items won't show at all, just the UA items. On 02/07/14 14:36, Wesley Hardman wrote: The current context menu event does suffer from the same issue. If this is implemented, there at least needs to be a matching dom.event.contextmenu.showall preference to always show all menu items. I don't think this proposal is worse, but it isn't really better. With the current event, I always have to hit escape when I actually DO need to get to a custom context menu, but I can still get to both. With this proposal, I have to expand to get to the UA items. Personally whenever I am right clicking on something, it usually to get to a UA option; rarely do I ever use the custom options (either way). With this proposal, my most used options are further away. On 2014-07-02 11:30, Ehsan Akhgari wrote: On 2014-07-02, 3:12 AM, Henri Sivonen wrote: On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: we are looking to implement an optional attribute that allows authors to disable the default context menu items so only the applications items are shown. I think we shouldn't do this, since it would be hostile to users. I think it would be OK to allow apps to request that the User Agent-provided context menu items be tucked away in a submenu, though. Note that this is something that web pages are already able to do. Do you think the contextmenu event that we currently support suffers from the same issue? Why is this proposal worse than that? Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
That doesn't work if you have Element Inspector installed (https://addons.mozilla.org/en-US/firefox/addon/element-inspector/). It is restart-less, so I suppose its easy to toggle on and off. On 2014-07-02 14:49, Jan Varga wrote: > Just FYI, the current implementation in Gecko also checks the shift key, > if it is pressed then custom context menu items won't show at all, just > the UA items. > > On 02/07/14 14:36, Wesley Hardman wrote: >> The current context menu event does suffer from the same issue. If this is >> implemented, there at least needs to be a matching >> dom.event.contextmenu.showall preference to always show all menu items. >> >> I don't think this proposal is worse, but it isn't really better. With the >> current event, I always have to hit escape when I actually DO need to get to >> a custom context menu, but I can still get to both. With this proposal, I >> have to expand to get to the UA items. Personally whenever I am right >> clicking on something, it usually to get to a UA option; rarely do I ever >> use the custom options (either way). With this proposal, my most used >> options are further away. >> >> On 2014-07-02 11:30, Ehsan Akhgari wrote: >>> On 2014-07-02, 3:12 AM, Henri Sivonen wrote: On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: > we are > looking to implement an optional attribute that allows authors to disable > the default context menu items so only the applications items are shown. I think we shouldn't do this, since it would be hostile to users. I think it would be OK to allow apps to request that the User Agent-provided context menu items be tucked away in a submenu, though. >>> Note that this is something that web pages are already able to do. Do >>> you think the contextmenu event that we currently support suffers from >>> the same issue? Why is this proposal worse than that? >>> >>> Cheers, >>> Ehsan >>> >> ___ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On 2014-07-02, 2:36 PM, Wesley Hardman wrote: The current context menu event does suffer from the same issue. If this is implemented, there at least needs to be a matching dom.event.contextmenu.showall preference to always show all menu items. I don't think this proposal is worse, but it isn't really better. With the current event, I always have to hit escape when I actually DO need to get to a custom context menu, but I can still get to both. With this proposal, I have to expand to get to the UA items. Hmm, not sure what you mean by expanding... We can still show the UA context menu if you hold down shift like we do today though. > Personally whenever I am right clicking on something, it usually to get to a UA option; rarely do I ever use the custom options (either way). With this proposal, my most used options are further away. Is it perhaps because most web pages do not have a useful custom context menu? Would you say the same thing about, let's say, Google Docs? The Google Docs custom context menus seem like a great use case for this to me. Cheers, Ehsan On 2014-07-02 11:30, Ehsan Akhgari wrote: On 2014-07-02, 3:12 AM, Henri Sivonen wrote: On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: we are looking to implement an optional attribute that allows authors to disable the default context menu items so only the applications items are shown. I think we shouldn't do this, since it would be hostile to users. I think it would be OK to allow apps to request that the User Agent-provided context menu items be tucked away in a submenu, though. Note that this is something that web pages are already able to do. Do you think the contextmenu event that we currently support suffers from the same issue? Why is this proposal worse than that? Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
Just FYI, the current implementation in Gecko also checks the shift key, if it is pressed then custom context menu items won't show at all, just the UA items. On 02/07/14 14:36, Wesley Hardman wrote: The current context menu event does suffer from the same issue. If this is implemented, there at least needs to be a matching dom.event.contextmenu.showall preference to always show all menu items. I don't think this proposal is worse, but it isn't really better. With the current event, I always have to hit escape when I actually DO need to get to a custom context menu, but I can still get to both. With this proposal, I have to expand to get to the UA items. Personally whenever I am right clicking on something, it usually to get to a UA option; rarely do I ever use the custom options (either way). With this proposal, my most used options are further away. On 2014-07-02 11:30, Ehsan Akhgari wrote: On 2014-07-02, 3:12 AM, Henri Sivonen wrote: On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: we are looking to implement an optional attribute that allows authors to disable the default context menu items so only the applications items are shown. I think we shouldn't do this, since it would be hostile to users. I think it would be OK to allow apps to request that the User Agent-provided context menu items be tucked away in a submenu, though. Note that this is something that web pages are already able to do. Do you think the contextmenu event that we currently support suffers from the same issue? Why is this proposal worse than that? Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
The current context menu event does suffer from the same issue. If this is implemented, there at least needs to be a matching dom.event.contextmenu.showall preference to always show all menu items. I don't think this proposal is worse, but it isn't really better. With the current event, I always have to hit escape when I actually DO need to get to a custom context menu, but I can still get to both. With this proposal, I have to expand to get to the UA items. Personally whenever I am right clicking on something, it usually to get to a UA option; rarely do I ever use the custom options (either way). With this proposal, my most used options are further away. On 2014-07-02 11:30, Ehsan Akhgari wrote: > On 2014-07-02, 3:12 AM, Henri Sivonen wrote: >> On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: >>> we are >>> looking to implement an optional attribute that allows authors to disable >>> the default context menu items so only the applications items are shown. >> >> I think we shouldn't do this, since it would be hostile to users. I >> think it would be OK to allow apps to request that the User >> Agent-provided context menu items be tucked away in a submenu, though. > > Note that this is something that web pages are already able to do. Do > you think the contextmenu event that we currently support suffers from > the same issue? Why is this proposal worse than that? > > Cheers, > Ehsan > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On 02.07.2014 17:30, Ehsan Akhgari wrote: On 2014-07-02, 3:12 AM, Henri Sivonen wrote: On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: we are looking to implement an optional attribute that allows authors to disable the default context menu items so only the applications items are shown. I think we shouldn't do this, since it would be hostile to users. I think it would be OK to allow apps to request that the User Agent-provided context menu items be tucked away in a submenu, though. Note that this is something that web pages are already able to do. Do you think the contextmenu event that we currently support suffers from the same issue? Why is this proposal worse than that? It suffers from the same issue and does indeed annoy me as a user from time to time (e.g. with youtube's html player). However, the spec at least allows for bypassing this behavior: "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. 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." Gecko supports dom.event.contextmenu.enabled to that end. It used to be a visible preference in Firefox, but now it's merely a hidden one. Dao ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On 2014-07-02, 3:12 AM, Henri Sivonen wrote: On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: we are looking to implement an optional attribute that allows authors to disable the default context menu items so only the applications items are shown. I think we shouldn't do this, since it would be hostile to users. I think it would be OK to allow apps to request that the User Agent-provided context menu items be tucked away in a submenu, though. Note that this is something that web pages are already able to do. Do you think the contextmenu event that we currently support suffers from the same issue? Why is this proposal worse than that? Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On Sun, Jun 29, 2014 at 4:53 AM, Dale Harvey wrote: > we are > looking to implement an optional attribute that allows authors to disable > the default context menu items so only the applications items are shown. I think we shouldn't do this, since it would be hostile to users. I think it would be OK to allow apps to request that the User Agent-provided context menu items be tucked away in a submenu, though. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
Am Sonntag, 29. Juni 2014 03:53:21 UTC+2 schrieb Dale Harvey: > however they are currently shown in addition to the default items, we are > looking to implement an optional attribute that allows authors to disable > the default context menu items so only the applications items are shown. Please take a look at my proposal a while ago here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=12999#c22 (There's more discussion in the Bug) Please note that the current Firefox implementation of context menus does not follow the latest spec. This should probably be updated first. However, the longer I'm thinking about it, it'd be the best (IMHO) to not have declarative way to extend/modify the context menu, but instead have an API for that. One reason is that most applications of do not make much sense without having JS listening for events. Another is the different UI/UX concepts of mobile vs desktop, and it's very hard to handle this declaratively without a boatload of attributes which IMHO makes it too complex. I do have some simple ideas for an API, and once my thesis is finished, I may take a shot at sketching up a spec. Will take a few weeks, though. Best regards --fbender ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
Suppressing the contextmenu is extremely user-hostile (for some users). There is a reason I always run with dom.event.contextmenu.enabled set to false. If anything alters the existing context menu, make sure there is a pref to disable it. Even the disclosure chevron would be annoying to me. On 2014-06-29 00:30, Ian Hickson wrote: > On Sat, 28 Jun 2014, Dale Harvey wrote: >> >> Application developers have the ability to specify additional menuitems for >> contextmenus via >> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus >> however they are currently shown in addition to the default items, we are >> looking to implement an optional attribute that allows authors to disable >> the default context menu items so only the applications items are shown. >> This is primarily targeted for Firefox OS, I believe Jonas will be looking >> to add it to the official spec. >> >> The name / value of the attribute is under discussion >> >> >> >> >> >> looks like the most likely candidate. > > This has been suggested many times, but the reason it's not part of the > standard is that it's user-hostile. > > I would recommend that instead of letting the author prevent the user from > getting to the user's browser's commands, the browser instead simply hide > the browser commands behind a disclosure chevron, as in this example: > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#dom-contextmenu > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Ability to surpress default contextmenu items
On Sat, 28 Jun 2014, Dale Harvey wrote: > > Application developers have the ability to specify additional menuitems for > contextmenus via > http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#context-menus > however they are currently shown in addition to the default items, we are > looking to implement an optional attribute that allows authors to disable > the default context menu items so only the applications items are shown. > This is primarily targeted for Firefox OS, I believe Jonas will be looking > to add it to the official spec. > > The name / value of the attribute is under discussion > > > > > > looks like the most likely candidate. This has been suggested many times, but the reason it's not part of the standard is that it's user-hostile. I would recommend that instead of letting the author prevent the user from getting to the user's browser's commands, the browser instead simply hide the browser commands behind a disclosure chevron, as in this example: http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#dom-contextmenu -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
