Closed Bug 746087 Opened 12 years ago Closed 5 years ago

Implement HTML5 toolbar menus

Categories

(Core :: DOM: Core & HTML, defect, P5)

defect

Tracking

()

RESOLVED INVALID

People

(Reporter: janv, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tw-dom])

Attachments

(3 files)

      No description provided.
Assignee: nobody → Jan.Varga
Status: NEW → ASSIGNED
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!
(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
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.
Attached image screenshot
here's an old screenshot, will attach a new one and also a WIP patch
Attached image more recent screenshot
Attached patch WIP patchSplinter Review
Blocks: html
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)
Tim, see Bug 897102.
Depends on: 897102, 617528
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)
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)
Blocks: 1251394
(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.
(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.
(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
No longer blocks: 1251394
Priority: -- → P5
See Also: → 1372276
Blocks: 897102
No longer depends on: 897102
I'm going to close this since this bug is quite confusing. Let's use bug 897102 to align with the standard.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: