Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove the context menu feature #2742

Merged
merged 6 commits into from
Jun 8, 2017
Merged

Remove the context menu feature #2742

merged 6 commits into from
Jun 8, 2017

Conversation

domenic
Copy link
Member

@domenic domenic commented Jun 6, 2017

This feature sadly never garnered enough implementation interest, being
only implemented in Gecko. For some time it looked as though Blink was
also interested in implementing, but they recently made the decision to
cease implementation and remove all of their code for it, per
https://bugs.chromium.org/p/chromium/issues/detail?id=87553&desc=2#c64.

Closes #2730.


Tests: web-platform-tests/wpt#6167

@sideshowbarker, @zcorpan, any thoughts on whether <menu> should be simplified further to only allow <li>s, like <ul>? Or should we keep it as allowing either <li>s or "if the element has no li element children, flow content describing available commands"?

This feature sadly never garnered enough implementation interest, being
only implemented in Gecko. For some time it looked as though Blink was
also interested in implementing, but they recently made the decision to
cease implementation and remove all of their code for it, per
https://bugs.chromium.org/p/chromium/issues/detail?id=87553&desc=2#c64.

Closes #2730.
@zcorpan
Copy link
Member

zcorpan commented Jun 7, 2017

Allowing only <li> sounds OK. I imagine the mixed content model is terrible for editing apps.

@domenic
Copy link
Member Author

domenic commented Jun 7, 2017

Thanks for the additional finds and fixes; they all look good. I'll add some tests for the UA stylesheet.

@sideshowbarker
Copy link
Contributor

any thoughts on whether <menu> should be simplified further to only allow <li>s, like <ul>? Or should we keep it as allowing either <li>s or "if the element has no li element children, flow content describing available commands"?

Allowing only <li> sounds OK. I imagine the mixed content model is terrible for editing apps.

Agreed, for that kind of reason it make sense to restrict it to allowing only <li>. We can always loosen the restriction later of reasonable use cases end up coming forward.

@zcorpan
Copy link
Member

zcorpan commented Jun 8, 2017

It would be nice to hear something from Mozilla folks before merging this. If they decide to keep the feature I suppose they want to have the tests in some non-wpt location or so. @jgraham?

@zcorpan
Copy link
Member

zcorpan commented Jun 8, 2017

I meant that for web-platform-tests/wpt#6167

@domenic domenic merged commit e7e8c88 into master Jun 8, 2017
@domenic domenic deleted the rm-context-menus branch June 8, 2017 18:16
domenic added a commit to web-platform-tests/wpt that referenced this pull request Jun 8, 2017
sideshowbarker pushed a commit to web-platform-tests/wpt that referenced this pull request Jun 8, 2017
Remove tests for, and test the removal of, context menus

Follows whatwg/html#2742.

Also test computed style (i.e. UA stylesheet)
sideshowbarker pushed a commit to validator/tests that referenced this pull request Jun 24, 2017
Remove tests for, and test the removal of, context menus

Follows whatwg/html#2742.

Also test computed style (i.e. UA stylesheet)
sideshowbarker added a commit to validator/validator that referenced this pull request Jun 25, 2017
This change disallows the "contextmenu" attribute and type=contextmenu
and type=toolbar for the `menu` element.

See whatwg/html#2742

Fixes #526
@rniwa
Copy link

rniwa commented Oct 31, 2017

Interestingly, we're considering to implement this feature in https://bugs.webkit.org/show_bug.cgi?id=179020.

jugglinmike added a commit to bocoup/html-aam that referenced this pull request Sep 6, 2019
In 2015, the "popup" value of the `<menu>` element's `type` attribute
was renamed to "context" [1]. In 2017, the `<menuitem>` element and the
`type` attribute of the `<menu>` element were removed entirely [2].

Remove the rows that describe these features.

[1] whatwg/html#241
[2] whatwg/html#2742
jugglinmike added a commit to bocoup/html-aam that referenced this pull request Sep 7, 2019
In 2015, the "popup" value of the `<menu>` element's `type` attribute
was renamed to "context" [1]. In 2017, the `<menuitem>` element and the
`type` attribute of the `<menu>` element were removed entirely [2].

Remove the rows that describe these features.

[1] whatwg/html#241
[2] whatwg/html#2742
andreubotella added a commit to andreubotella/pointerevents that referenced this pull request Jan 19, 2022
The reference to the `contextmenu` event in 4.2.12 links to the HTML
spec, even though any non-editorial mentions of that event –but not the
definition in the event list– were removed (apparently by mistake) in
whatwg/html#2742. That event was subsequently added to the UI Events
spec in w3c/uievents#279, and now the definition in the HTML spec's
event list has been removed in whatwg/html#7506. This change updates
the reference to link to the UI Events spec.
patrickhlauke pushed a commit to w3c/pointerevents that referenced this pull request Jan 19, 2022
The reference to the `contextmenu` event in 4.2.12 links to the HTML
spec, even though any non-editorial mentions of that event –but not the
definition in the event list– were removed (apparently by mistake) in
whatwg/html#2742. That event was subsequently added to the UI Events
spec in w3c/uievents#279, and now the definition in the HTML spec's
event list has been removed in whatwg/html#7506. This change updates
the reference to link to the UI Events spec.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging this pull request may close these issues.

4 participants