Closed
Bug 897102
Opened 11 years ago
Closed 2 years ago
Update <menu> to spec
Categories
(Core :: DOM: Core & HTML, enhancement, P5)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
INACTIVE
People
(Reporter: Ms2ger, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: dev-doc-needed)
<Hixie> anyone know if gecko has any plans to update its <menu> implementation to match the spec? (the spec was changed at some point to more closely match firefox, but there were some things that didn't quite match firefox for sanity reasons)
Comment 1•11 years ago
|
||
I'd like to update it to match the spec, but it's not a priority at the moment. Maybe in Q4.
Comment 2•11 years ago
|
||
Bug 617528 should be added as a dependancy to keep the overview.
Spec is here: http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#menus (and following sections).
Hixie wrote an overview over the differences between the spec changes and the Firefox implementation[1] (as of Dec 2012):
> - Gecko doesn't support <hr>.
Bug 870388.
> - Gecko's parser doesn't treat <menuitem> as a void element.
> […]
> - Gecko uses the first text node of the <menuitem> element as a label if
> there's no label="" attribute.
> I don't see much point supporting this, especially if we make it void.
Both part of Bug 676236!? (Bug has a checked in patch but is still open.)
The following items have no bug filed:
> - <menu type=popup> is implemented as <menu type=context> in Gecko.
I don't know if this is straight renaming or also a slight rewriting.
> - <menuitem command=""> is not supported in Gecko.
> - Gecko doesn't support contextmenu="" pointing at a <menu> child of a
> <menu type=context> (popup, in spec).
> - Gecko doesn't drop submenus with no label (it does drop items with no
> label, at least in most cases, and seems to strip separators as the
> spec suggests).
> - Gecko doesn't support <button type=menu menu="">.
There's also a mention of how default/"native" context menu items should be displayed (or not) in the spec. There was some discussion on the mailing list and W3C-Bug-12999[2] which is of yet unresolved. See also Bug 705292.
[1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-December/038472.html
[2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=12999
Updated•11 years ago
|
Keywords: dev-doc-needed
Comment 4•11 years ago
|
||
(In reply to :Ms2ger from comment #3)
> Hey Jan, Q4 is here! Got time now? :)
I doubt I will have time in Q4, maybe next quarter.
Flags: needinfo?(Jan.Varga)
Updated•11 years ago
|
Comment 5•10 years ago
|
||
Any updates on this?
Comment 6•10 years ago
|
||
Adding to comment 2:
"The missing value default is the popup menu state if the parent element is a menu element whose type attribute is in the popup menu state; otherwise, it is the toolbar state."
https://html.spec.whatwg.org/multipage/forms.html#dom-menu-type
document.createElement('menu').type returns 'list', should be 'toolbar' per spec.
<menu type=popup><menu>.type should be 'popup' per spec. (Also <menu type=popup><menu><menu>.type)
Comment hidden (typo) |
Comment 8•10 years ago
|
||
The last call spec above documents type context, toolbar, list -- but not popup.
Reporter | ||
Comment 9•10 years ago
|
||
The link you provided is not relevant to anything; the spec is at <https://html.spec.whatwg.org/multipage/>.
Comment 10•10 years ago
|
||
(In reply to :Ms2ger from comment #9)
> The link you provided is not relevant to anything; the spec is at
> <https://html.spec.whatwg.org/multipage/>.
Thanks for the clarification. I must have googled myself into a hole with that now irrelevant reference.
Looks like menu is not part of http://www.w3.org/TR/html5/ but only http://www.w3.org/TR/html51/ right?
My testing of a contextmenu in a web app I work on shows in both Nightly Firefox on Windows and Nightly Firefox OS that type="popup" is always displaying. I have to use type="context" instead.
And this is exactly what this bug is again, right?
So the documentation in
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/menu
is not only hard to understand, it is also currently wrong.
I guess I should update it to document type="context" now (and resolve bug 1140838) and change it again once this bug 897102 is fixed, right?
Comment 11•10 years ago
|
||
The MDN documentation is correct, and matches the WHATWG HTML5 spec (which supercedes the W3C HTML5 spec): https://html.spec.whatwg.org/multipage/forms.html#the-menu-element
As per the spec, valid types are "popup" and "toolbar".
Firefox currently implements types "context" and "list", which are not part of the WHATWG HTML5 spec.
Chromium has started to support type="popup" behind a flag.
Comment 12•10 years ago
|
||
(In reply to dvpdiner2 from comment #11)
> The MDN documentation is correct, and matches the WHATWG HTML5 spec (which
I should have phrased this differently.
While MDN documentation conforms to the spec, following it will not work in current nightly Firefox on Windows or Firefox OS.
Meanwhile I have added a note to
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Menu#Summary
stating...
Note: This documentation describes current Firefox implementation. Type 'list' is likely to change to 'toolbar' and 'context' to 'popup' according to HTML5.1 working draft.
and documented current implementation.
> supercedes the W3C HTML5 spec):
> https://html.spec.whatwg.org/multipage/forms.html#the-menu-element
>
> As per the spec, valid types are "popup" and "toolbar".
> Firefox currently implements types "context" and "list", which are not part
> of the WHATWG HTML5 spec.
>
> Chromium has started to support type="popup" behind a flag.
Comment 13•10 years ago
|
||
(In reply to adrian.aichner from comment #7)
Typo fix:
I guess bug 1140838 can not quickly be fixed considering https://bugzilla.mozilla.org/showdependencygraph.cgi?id=1140838.
Meanwhile I have updated MDN to current implementation and will update again once bug 1100749 is fixed.
Updated•6 years ago
|
Priority: -- → P5
Updated•5 years ago
|
Type: defect → enhancement
Updated•2 years ago
|
Severity: normal → S3
Comment 14•2 years ago
|
||
Feature was removed in bug 1372276
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → INACTIVE
You need to log in
before you can comment on or make changes to this bug.
Description
•