Re: [whatwg] <menu> and friends

On Wed, 9 Jan 2013, Henri Sivonen wrote:
> On Sat, Dec 29, 2012 at 3:23 AM, Ian Hickson <ian@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.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 9 January 2013 20:24:06 UTC