The default bug view has changed. See this FAQ.

Implement HTML5 toolbar menus

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
5 years ago
7 months ago

People

(Reporter: janv, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 2 bugs, {dev-doc-needed})

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [tw-dom])

Attachments

(3 attachments)

Comment hidden (empty)
(Reporter)

Updated

5 years ago
Assignee: nobody → Jan.Varga
Status: NEW → ASSIGNED
(Reporter)

Comment 1

5 years ago
Should this implementation follow the proposal at https://www.w3.org/Bugs/Public/show_bug.cgi?id=13608#c6 ?

So the syntax would be:
<toolbar>
  <toolbarbutton>
  <toolbarbutton>
  ...
</toolbar>
Adding yet another random unspec'ed tag? Browser wars came again!
(Reporter)

Comment 3

5 years ago
(In reply to Masatoshi Kimura [:emk] from comment #2)
> Adding yet another random unspec'ed tag? Browser wars came again!

No, we're going to discuss about it first
(Reporter)

Comment 4

5 years ago
anyway, the <menuitem> is not in the standard :)
(In reply to Jan Varga [:janv] from comment #3)
> (In reply to Masatoshi Kimura [:emk] from comment #2)
> > Adding yet another random unspec'ed tag? Browser wars came again!
> No, we're going to discuss about it first
And it appears that a spec editor oppose adding <menuitem>. Moreover, the spec bug was filed after Henri pointed out in bug 676236 comment #2.
(In reply to Jan Varga [:janv] from comment #4)
> anyway, the <menuitem> is not in the standard :)
Then making things even worse?
(In reply to Masatoshi Kimura [:emk] from comment #5)
> And it appears that a spec editor oppose adding <menuitem>.
So? If the spec is bad, it should be changed.
(Reporter)

Comment 7

5 years ago
Created attachment 619915 [details]
screenshot

here's an old screenshot, will attach a new one and also a WIP patch
(Reporter)

Comment 8

5 years ago
Created attachment 619921 [details]
more recent screenshot
(Reporter)

Comment 9

5 years ago
Created attachment 619936 [details] [diff] [review]
WIP patch

Updated

5 years ago
Blocks: 568516
Blocks: 802882

Comment 10

3 years ago
The spec changes a little bit, menuitem is back I guess. menu[type="context"] is now menu[type="popup"] same for <menu>
Flags: needinfo?(Jan.Varga)

Comment 11

3 years ago
Tim, see Bug 897102.
Depends on: 897102, 617528
(Reporter)

Comment 12

3 years ago
Yeah, the spec has changed (mostly the way we wanted), but unfortunately updating our implementation is not a priority at the moment :(
Flags: needinfo?(Jan.Varga)
Keywords: dev-doc-needed

Comment 13

a year ago
Jan, any chance you can resume development on this bug? This has gotten much more relevant, especially in the light of XUL deprecation, and it'll allow many parts of the UI to be rewritten in HTML (Developer Tools for example).
Flags: needinfo?(jvarga)

Updated

a year ago
Blocks: 1251394
(Reporter)

Comment 14

a year ago
(In reply to Tim Nguyen [:ntim] from comment #13)
> Jan, any chance you can resume development on this bug? This has gotten much
> more relevant, especially in the light of XUL deprecation, and it'll allow
> many parts of the UI to be rewritten in HTML (Developer Tools for example).

I don't have the time currently, but maybe someone else from the DOM team could take it.
Flags: needinfo?(jvarga)
Whiteboard: [tw-dom]
I'm not convinced this bug is worth fixing. At the very least we should check that other browsers are interested before we implement anything. If we end up being the only one implementing, developers are very unlikely to use this.
(In reply to Jonas Sicking (:sicking) from comment #15)
> I'm not convinced this bug is worth fixing. At the very least we should
> check that other browsers are interested before we implement anything. If we
> end up being the only one implementing, developers are very unlikely to use
> this.

Sure.
Assignee: jvarga → nobody
Status: ASSIGNED → NEW
According to http://html5accessibility.com/, we support menuitem, and partially menu popups, and we're the only ones doing so. If we implemented this fully, it would give us an edge and maybe entice others to follow our lead, alleviating the need for ugly hacks web developers need to implement nowadays for such menu systems.

Comment 18

a year ago
(In reply to Jonas Sicking (:sicking) from comment #15)
> If we
> end up being the only one implementing, developers are very unlikely to use
> this.

If a feature is wanted and its implementation was decent then wouldn't developers prefer to create polyfills, that seems to be less painful than to implement a feature for all browsers from scratch.

Comment 19

a year ago
(In reply to Jonas Sicking (:sicking) from comment #15)
> I'm not convinced this bug is worth fixing. At the very least we should
> check that other browsers are interested before we implement anything. If we
> end up being the only one implementing, developers are very unlikely to use
> this.

If it helps, other browsers are finally stirring on the context menu support that Firefox has had for a while.

Chrome's got an implementation of the context menu support but it's being held behind an experimental feature flag because they followed the spec more closely than Firefox, it broke a site, and discussions on changing the spec apparently went nowhere.

https://bugs.chromium.org/p/chromium/issues/detail?id=87553 (implementation)
https://bugs.chromium.org/p/chromium/issues/detail?id=412945 (site evangelism bug)

I don't know how accurate it is, but caniuse.com claims that Opera inherited that ability by their use of Blink:

http://caniuse.com/#feat=menu

As for Edge, there's a UserVoice request to support it and Microsoft has the feature listed as under consideration (probably because of the aforementioned issue Chrome ran into).

https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/6508881-html5-menu-tag-contextmenu-attribute
https://dev.windows.com/en-us/microsoft-edge/platform/status/menuelement

Updated

11 months ago
No longer blocks: 1251394
You need to log in before you can comment on or make changes to this bug.