Re: [whatwg] <menu> and friends

On Wed, Jan 9, 2013 at 10:17 PM, Ian Hickson <ian@hixie.ch> wrote:
> Optimising for the short-term shim author's experience rather than the
> long-term HTML authoring experience seems backwards to me.

After input from a couple of other Gecko developers, I withdraw my
objection to <menuitem> being void.

>> 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.

Even if we accept, for the sake of the argument, that the current
parsers will be gone in 10 years, it is incorrect to consider only
parsers. Considering serializers is also relevant. The voidness of
"command" has already propagated to various places—including
serializer specs like
http://www.w3.org/TR/xslt-xquery-serialization-30/ . (No doubt the
XSLT folks will be super-happy when we tell them that the list of void
elements has changed again.)

At any point of the future, it is more likely that picking a new
element name for a newly-minted non-void element will cause less
(maybe only an epsilon less but still less) hassle than trying to
re-introduce "command" as non-void. Why behave as if finite-length
strings were in short supply? Why not treat "command" as a burned name
just like "legend" and pick something different the next time you need
something of the same theme when interpreted as an English word?

What makes an element "exist" for you? Evidently, basefont and bgsound
exist enough to get special parsing and serialization treatment. Is
multiple interoperable parsing and serialization implementations not
enough of existence and you want to see deployment in existing
content, too? Did you measure the non-deployment of <command> on the
Web or are we just assuming it hasn't been used in the wild? Even if
only a few authors have put <command> in <head>, changing parsing to
make <command> break out of <head> is bad.

What do we really gain except for test case churn, makework in code
and potential breakage from changing "command" as opposed to treating
it as a used-up identifier and minting a new identifier in the future
if a non-void element with a "command"-like name is needed in the
future?

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 14 January 2013 08:07:44 UTC