This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24754 - menuitem and backward compatibility
Summary: menuitem and backward compatibility
Status: RESOLVED DUPLICATE of bug 24972
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 major
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-20 21:24 UTC by Andrea Rendine
Modified: 2014-03-11 00:28 UTC (History)
4 users (show)

See Also:


Attachments

Description Andrea Rendine 2014-02-20 21:24:02 UTC
http://www.w3.org/TR/html51/interactive-elements.html#the-menuitem-element
This element has "empty" as content model, in fact in the example it behaves like other element with the same content model. I.e., there is only the opening tag. But in the description it is not stated that the closing tag is omissible, maybe for legacy browsers (the element wouldn't build a backward-compatible DOM subtree as every subsequent menuitem is placed inside the preceding one(s). In addition to this, Validator.w3.org/nu validates the menuitem expressed via self-closing tag in XHTML documents, but in HTML document both <menuitem> without closing tag and the self-closing slash are considered invalid (in the former case the tag is considered still open, in the latter the error thrown is [[Self-closing syntax (/>) used on a non-void HTML element. Ignoring the slash and treating as a start tag.]]. Which is obviously inconsistent with the spec, as the element IS void.
To both solve the background compatibility and the consistency issues, you should:
 - either state that the tag is NOT omissible (and given the particularity of this case I would suggest to highlight this issue) and correct the example
 - or correct the validator issues and the description, stating that the closing tag is actually omissible but forcing the element inside a container like a <p> or <label> element.
Otherwise, we'll end up having different requirements and different DOM trees for HTML and XHTML and/or an unusable element due to lacking support in UAs.
Comment 1 Andrea Rendine 2014-03-11 00:28:39 UTC
After a public discussion in the Validator mailing list and a deeper reading of the spec, I saw that the <menuitem> element has not only content model "empty", but it is also in the cathegory of void elements (i.e. elements which can only have a start tag, eventually with the syntax borrowed from XML self-closing element). But it is dangerous because once it becomes widely used, browsers not supporting it will make errors (see Bug 24972).
Therefore I will close this bug as duplicate of the one cited above.

*** This bug has been marked as a duplicate of bug 24972 ***