W3C home > Mailing lists > Public > www-archive@w3.org > February 2014

Re: Procedural (non-technical) point about freezing the cat and hat combinators before they've even been defined (was Re: Shadow DOM: Hat and Cat -- if that's your real name.)

From: Sylvain Galineau <galineau@adobe.com>
Date: Thu, 6 Feb 2014 16:56:07 +0000
To: Peter Moulder <pjrm@mail.internode.on.net>
CC: "<www-style@w3.org>" <www-style@w3.org>, "www-archive@w3.org" <www-archive@w3.org>
Message-ID: <C380CB28-D65F-42A5-8392-8DF4F2071802@adobe.com>

On Feb 5, 2014, at 10:34 PM, Peter Moulder <pjrm@mail.internode.on.net> wrote:

> On Tue, Feb 04, 2014 at 06:22:33PM -0800, Edward O'Connor wrote:
>> In the CSS WG we've historically allowed implementations to ship
>> unprefixed properties when the spec containing those properties hits CR.
>> Selector combinators are a funny case—they can't be prefixed—so we
>> should be extra careful about shipping them prematurely.
>> But as far as I can tell, these combinators *aren't even [in a spec that's
>> visible enough to receive wider discussion]*, much less in a spec that's hit
>> (or will soon hit) CR. This seems highly irregular.
> Just to state explicitly in this thread the idea that no doubt many people have
> had in mind:
> One way out of this is to ship it prefixed, as in ^-webkit-cat or /-moz-hat
> or whatever other <combinator-prefix> you fancy from the "Pseudo-elements
> vs. combinators" thread.  This doesn't even commit CSS to a particular choice
> of <combinator-prefix> (to the extent that any prefixed feature can be
> retracted), because the shipped choice would only ever be used in conjunction
> with a vendor prefix.

That is one way to prefix a combinator, yes. But to the extent Google wants to maximize the odds this specific bit of the feature will remain unchanged, a prefix should be sub-optimal.

Still, it is true that the combinator naming proposal would allow you to prefix an experimental one. Given how I feel about prefixes I’m reluctant to consider it a plus but there you have it.

> (Whether such an approach is useful depends in part on whether a prefixed
> implementation is a sufficient response to the importance of pushing forward
> quickly that Google perceives.)
> pjrm.
Received on Thursday, 6 February 2014 16:56:57 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 6 February 2014 16:56:57 UTC