[whatwg] <menu> and friends
ian at hixie.ch
Wed Jan 9 12:17:59 PST 2013
On Wed, 9 Jan 2013, Henri Sivonen wrote:
> On Sat, Dec 29, 2012 at 3:23 AM, Ian Hickson <ian at hixie.ch> wrote:
> > * <menuitem> is void (requires parser changes).
> > * <command> is entirely gone. (Actually, I renamed <command> to <menuitem>
> > and made it so it's only allowed in <menu>.)
> Did you actually make these changes to the parsing algorithm?
I intended to, not sure how that escaped. Fixed.
> Currently, menuitem is non-void in Firefox.
Yeah, I saw that when writing examples for it. It's obviously bad for
authors when you try to use it.
> It was initially designed to be void but that never shipped and the
> non-voidness is, AFAIK, considered intentional. For one thing, being
> non-void makes the element parser-neutral and, therefore, easier to
> polyfill in menuitem-unaware browsers.
Optimising for the short-term shim author's experience rather than the
long-term HTML authoring experience seems backwards to me.
> As for <command> behavior in the parser, all major browsers have shipped
> releases with <command> as void, so we won't be able to reliably
> introduce a non-void element called "command" in the future anyway.
> Therefore, I don't see value in removing the voidness of "command" from
> parsing or serialization.
The element doesn't exist, so there's no value in having it. We can easily
introduce a non-void <command> in ten years if we need to, since by then
the current parsers will be gone.
> Could you, please, revert the serializing algorithm to treat <command>
> as void and <menuitem> as non-void?
That would make no sense, IMHO.
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg