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

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