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 25325 - What is the rationale in having <menuitem> as a void element? It won't be backward compatible, and in addition to this if it had content allowed in form of text nodes, the label for the command could [...]
Summary: What is the rationale in having <menuitem> as a void element? It won't be bac...
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard: blocked awaiting response from master...
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-11 13:15 UTC by contributor
Modified: 2016-02-05 11:35 UTC (History)
5 users (show)

See Also:
philipj: needinfo? (Ms2ger)


Attachments

Description contributor 2014-04-11 13:15:23 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#elements-0
Complete: http://www.whatwg.org/c#elements-0
Referrer: http://www.whatwg.org/specs/web-apps/current-work/multipage/index.html

Comment:
What is the rationale in having <menuitem> as a void element? It won't be
backward compatible, and in addition to this if it had content allowed in form
of text nodes, the label for the command could be specified by the textContent
of the element, in a way similar to <option> element.

Posted from: 94.38.225.93
User agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36
Comment 1 Andrea Rendine 2014-04-25 00:00:56 UTC
Define menuitem.textContent as the first option for the menu command's label. It will made context (popup) menus available to legacy UAs. Although a thorough support is necessary to have real context menus, the functionality of a popup menu relies upon the script. And the script can be executed by legacy UAs, too. Hence, the idea that the label can be given by the readable textContent of <menuitem>. This way, the label itself could also be stylable.
Comment 2 Ian 'Hixie' Hickson 2014-04-28 23:22:52 UTC
Why wouldn't it be backwards compatible?

Using an attribute is more or less specifically to prevent the use of elements, since many menu systems only accept text.
Comment 3 Andrea Rendine 2014-04-28 23:37:48 UTC
Because subsequent menuitem elements are treated as nested. The same result which is obtained at the moment by the validator parsing mechanism.
<menu type="popup"><menuitem><menuitem></menu>

intended DOM
 menu
  + menuitem
  + menuitem

resulting DOM in unsupporting UAs
 menu
  + menuitem
     + menuitem

The problem can be solved quickly. Allow text child nodes inside menuitem and consider as label the textContent for the element, the same which happens for several form controls.
Comment 4 Ian 'Hixie' Hickson 2014-04-29 21:53:52 UTC
In unsupporting UAs, the element is just ignored, so there's no back-compat problem as far as I can tell.
Comment 5 Andrea Rendine 2014-04-29 22:05:40 UTC
Isn't there any better option? Showing the popup menu relies upon supporting UAs, but the menu commands work thanks to javascript function, as far as I can tell. There's nothing in popup menu mechanics which cannot be acheved by unsupporting user agents, besides its display. So for unsupporting UAs it would be better to parse the elements correctly. At least the related subtree would be available, and this way the menu could be shown somehow (perhaps relying on polyfill scripts).
Comment 6 Ian 'Hixie' Hickson 2014-04-30 18:15:49 UTC
I'm more interested in making sure we have a good design on the long term than optimising for the transition period, to be honest. What's the argument for a different design on the long term?
Comment 7 Andrea Rendine 2014-04-30 19:49:47 UTC
One possible reason is that elements with text can be styled easily. IDK whether the future popup menus will rely on native support entirely or not, and in which kind of user agents. That is, will menu commands be associated with a native feature whose content is given by the markup instructions, or the menu will actually be shown as an HTML box element with absolute positioning whose visibility is regulated by the use of the left click / context menu key? I ask it because in the latter case, it would be useful for authors to style some commands. It also happens in some desktop programs, so in a logic of making a web page appear as an application, it would be significant. And in a logic of language consistency, HTML elements whose primary visual appearance is textual rely on their text content. In the meantime, I would like to make you notice that parsing text content is as easy as parsing an attribute. But the content itself is richer, has less caveats with characters which can be read, and therefore it's easier to produce for authors, in a language whose learning curve becomes more impervious by the day.
Have it not void, at least, so that it can be parsed properlt in legacy browsers. There's no simple way to force unsupporting UAs in parsing correctly void elements, also because the self-closing syntax has no effect in HTML. However, for legacy UAs, it would be better to have something to show, rather than nothing at all.
However for such a complex element and related feature, transition period is important and is expected to be long. Because authors could start using it NOW and test vendors' interest for this. And in future, it's highly unlikely that user agents will support it in the same time. In the logic of HTML spec, there seems to be something like a "legacy compatibility significance switch" which turns itself on and off randomly, sometimes it's an obstacle stopping every enhancement, other times it's of no interest. For authors it is interesting. And for vendors too.
Comment 8 Ian 'Hixie' Hickson 2014-05-05 23:22:12 UTC
(In reply to Andrea Rendine from comment #7)
> One possible reason is that elements with text can be styled easily.

The point of native context menus is that they're not styleable -- they fit into the platform's native aesthetic.


> And in a logic of language consistency, HTML elements
> whose primary visual appearance is textual rely on their text content.

One can equally argue that text that appears in native parts of the UI are typically in attributes (title="", placeholder="", value=""...). There's enough variety in HTML that you can argue for consistency in many ways. :-)


> In the meantime, I would like to make you notice that parsing text
> content is as easy as parsing an attribute.

Insofar as browsers have to support both regardless, sure.

But it's a lot easier to deal with attributes _after_ they are parsed, because you just have a string, whereas with element content you can have elements, text nodes, comment nodes, all kinds of nonsense.


> But the content itself is richer

That's the problem, in this case. We need text; anything more is just extra sources of bugs.


> has less caveats with characters which can be read

Not sure what you mean here.


> and therefore it's easier to produce for authors

I don't think it's easier or harder. If I had to make a call, I'd say a void element with attributes is easier than an element with attributes and content.


> Have it not void, at least, so that it can be parsed properly in legacy
> browsers.

If we have it non-void but use attributes, it would be really ugly to use.


> There's no simple way to force unsupporting UAs in parsing
> correctly void elements, also because the self-closing syntax has no effect
> in HTML. However, for legacy UAs, it would be better to have something to
> show, rather than nothing at all.

Actually, I think it would be better for legacy UAs not to show inert text that was supposed to go in context menus.

But as I said earlier, I'm more interested in making sure we have a good design on the long term than optimising for the transition period.


> However for such a complex element and related feature, transition period is
> important and is expected to be long.

I don't see why. Most browsers (by usage) have a very short update cycle these days.


> Because authors could start using it NOW and test vendors' interest for this.

They could do that now using <span>, if they wanted to.

(Indeed, they do. It's not unusual to see context menus made with <div>s and so on.)



> And in future, it's highly unlikely
> that user agents will support it in the same time. In the logic of HTML
> spec, there seems to be something like a "legacy compatibility significance
> switch" which turns itself on and off randomly, sometimes it's an obstacle
> stopping every enhancement, other times it's of no interest. For authors it
> is interesting. And for vendors too.

I don't understand what you're saying here.

I don't know why you'd use this feature before it was widely available; once it's widely available, there's not much reason to want the element to not be void, IMHO.
Comment 9 Andrea Rendine 2014-05-06 00:59:05 UTC
(In reply to Ian 'Hixie' Hickson from comment #8)
> it's a lot easier to deal with attributes _after_ they are parsed, because you just have a string, whereas with element content you can have elements, text nodes, comment nodes, all kinds of nonsense.
menuitem.textContent
Is it THAT difficult? How did we do with title tags, option tags, textarea tags and so on until now without turning mad? :-) (well actually I turned mad some time ago, but it's another story)

> > has less caveats with characters which can be read
> Not sure what you mean here.
Quotes to escape, for example.

> Actually, I think it would be better for legacy UAs not to show inert text that was supposed to go in context menus.
Why? Apart from having a modern appearance which interacts with the newest UAs, what's there in context menus which cannot be done in legacy UAs? As a matter of fact, most websites use context menus today, with different markup. Were <menu@type=popup> usable by now, those context menus would be done with a forward-compatible structure.

> Most browsers (by usage) have a very short update cycle these days.
Haha.
In my country 2% of users still use IE7.
Guess what? I should take away each and every one of their PCs (I'd really LOVE to).

> They could do that now using <span>, if they wanted to.
When did span elements become allowed inside menu@type=popup?

> I don't know why you'd use this feature before it was widely available
As I said before, some websites actually use it now. Wouldn't it be nice if they started to make popup menus with modern syntax?
Comment 10 Ian 'Hixie' Hickson 2014-05-06 18:15:16 UTC
> menuitem.textContent
> Is it THAT difficult? How did we do with title tags, option tags, textarea
> tags and so on until now without turning mad? :-) (well actually I turned
> mad some time ago, but it's another story)

<title>, <option>, and <textarea> all have much more complicated parsing rules than most elements. <option> involves having its own parser insertion mode. There's all kinds of complexity around these elements.

The problem is that "textContent" doesn't magically solve the problem. For one, it increases the performance cost of anything to do with the element — now you have to walk a tree, instead of just referencing a string. This goes from a trivial O(1) cost to an O(N) cost with a high constant factor.


> > > has less caveats with characters which can be read
> > Not sure what you mean here.
> Quotes to escape, for example.

Actually there's exactly as much to escape in an attribute (& and ") as in an element (& and <), if you just want to allow text.


> Why? Apart from having a modern appearance which interacts with the newest
> UAs, what's there in context menus which cannot be done in legacy UAs?

Nothing, people do it now. But we don't want the context menus appearing just randomly on the page, surely.


> > Most browsers (by usage) have a very short update cycle these days.
> Haha.
> In my country 2% of users still use IE7.
> Guess what? I should take away each and every one of their PCs (I'd really
> LOVE to).

Your statement doesn't disagree with mine, as far as I can tell.

And IE7's parser, IIRC, actually makes void elements more backwards compatible, so if that's your target, this may be easier than you think. :-)


> > They could do that now using <span>, if they wanted to.
> When did span elements become allowed inside menu@type=popup?

I'm saying you would just not use <menu> at all in the meantime.


> > I don't know why you'd use this feature before it was widely available
>
> As I said before, some websites actually use it now. Wouldn't it be nice if
> they started to make popup menus with modern syntax?

I think it's not a big deal one way or the other. They can use <div>s today, and when browser support this widely, switch to <menu>.

There's a danger when people use features before they're implemented that they'll do so in a way that conflicts with the feature, and then we end up not being able to deploy the feature. I'm not a big fan of people using features before they're ready.
Comment 11 Philip Jägenstedt 2016-02-04 17:47:33 UTC
Well this is interesting. It looks like in Gecko, menuitem isn't a void element:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3867

Ms2ger, you've been at least tangentially involved <https://bugzilla.mozilla.org/show_bug.cgi?id=838598>, do you know what's going on here?

(I was hoping to find this had already shipped as a void element in Firefox so we could close this as "ship has sailed", but no...)
Comment 12 Philip Jägenstedt 2016-02-05 11:35:25 UTC
Discussion has moved on to https://github.com/whatwg/html/issues/234