W3C home > Mailing lists > Public > www-style@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: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 05 Feb 2014 12:33:16 -0500
Message-ID: <52F275DC.5010901@mit.edu>
To: www-style@w3.org
On 2/5/14 11:03 AM, Tab Atkins Jr. wrote:
> There are numerous examples of similar things elsewhere in the WG's
> history, and even current behavior - 'will-change', for example, is
> probably going to be shipped by Firefox and Chrome before it reaches
> the "proper" level of maturity in the W3C Process.


'will-change' was discussed at some length, and there is general 
agreement for how it should work.  This was feasible because it's a 
pretty small feature.

For the case of Shadow DOM we're in a worse position, not least because 
it's not so much a small feature.  There are all sorts of known issues 
where people disagree about how it should work.  We're not talking edge 
cases here but things like how events actually propagate, how styles are 
inherited in the tree (because the spec says it works the same way as 
events propagate), how styles on the shadowRoot work, and how <content> 
behaves by default.

Maybe you do consider those edge cases?  I'm not sure.  Some of these 
(e.g. the <content> one) haven't exactly gotten a lot of discussion, so 
maybe no one cares about them in practice, but the issue with the event 
path and style inheritance seems pretty non-edge-case to me.

> Sometimes things
> are important enough that pushing forward a little faster is
> justified.

Sure, but there is a difference between shipping something people agree 
with in principle but the details aren't fully worked out yet and hoping 
that you didn't make any mistakes in the details and shipping something 
people are explicitly disagreeing with.

The posts that started this thread seemed to be doing the latter, while 
at the same time explicitly pointing out that once shipped the 
implementation would likely be frozen in short order.  I hope you can 
see how that came off as a little ... offputting.  That might not have 
been the intent, but it was the net effect.

I'm going to assume that the initial posts here were phrased 
unfortunately and hence misunderstood by everyone that read them.  So 
let's try to correct those misunderstandings.  Can you please clearly 
state what your plans are for shipping the feature, freezing or not 
freezing functionality, and resolving the outstanding disagreements 
about the behavior?

Received on Wednesday, 5 February 2014 17:33:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:18 UTC