Closed Bug 897102 Opened 11 years ago Closed 2 years ago

Update <menu> to spec

Categories

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

enhancement

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)
I'd like to update it to match the spec, but it's not a priority at the moment. Maybe in Q4.
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
Depends on: 617528
Blocks: html5test
Hey Jan, Q4 is here! Got time now? :)
Flags: needinfo?(Jan.Varga)
(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)
Blocks: 746087
Depends on: 676236
See Also: → 705292
Depends on: 870388
Any updates on this?
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)
Blocks: 1140838
The last call spec above documents type context, toolbar, list -- but not popup.
The link you provided is not relevant to anything; the spec is at <https://html.spec.whatwg.org/multipage/>.
(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?
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.
(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.
(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.
Depends on: 1372276
Depends on: 1241353
Priority: -- → P5
No longer blocks: 746087
Depends on: 746087
Blocks: html
Type: defect → enhancement
Severity: normal → S3

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.