746087 - Implement HTML5 toolbar menus

Status: NEW

Description

[Jan Varga [:janv]]

Comment 1

[Jan Varga [:janv]]

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>

Comment 2

[Masatoshi Kimura [:emk]]

Adding yet another random unspec'ed tag? Browser wars came again!

Comment 3

[Jan Varga [:janv]]

(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

Comment 4

[Jan Varga [:janv]]

anyway, the <menuitem> is not in the standard :)

Comment 5

[Masatoshi Kimura [:emk]]

(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?

Comment 6

[Olli Pettay [:smaug]]

(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.

Comment 7

[Jan Varga [:janv]]

Created attachment 619915 [details]
screenshot

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

Comment 8

[Jan Varga [:janv]]

Created attachment 619921 [details]
more recent screenshot

Comment 9

[Jan Varga [:janv]]

Created attachment 619936 [details] [diff] [review]
WIP patch

Comment 10

[Tim Nguyen :ntim]

The spec changes a little bit, menuitem is back I guess. menu[type="context"] is now menu[type="popup"] same for <menu>

Comment 11

[Florian Bender]

Tim, see Bug 897102.

Comment 12

[Jan Varga [:janv]]

Yeah, the spec has changed (mostly the way we wanted), but unfortunately updating our implementation is not a priority at the moment :(

Comment 13

[Tim Nguyen :ntim]

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).

Comment 14

[Jan Varga [:janv]]

(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.

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 16

[Andrew Overholt [:overholt]]

(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.

Comment 17

[Marco Zehe (:MarcoZ)]

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

[alexander :surkov]

(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

[Stephan Sokolow]

(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