This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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 ***