Re: Google's incubation-first standards process

Hi Rick,

Thanks for following up. Replying to a couple of your points, slightly out of order.

> I don't want to rehash the whole debate we had at TPAC <https://lists.w3.org/Archives/Public/www-style/2016Nov/0077.html> around the WICG this in this forum (since it's virtually guaranteed to turn into a centi-thread fight, and we all have more valuable things to do with our time and emotional energy).

I know it takes energy to argue these things. It takes mine too. I think it's worth a shot, as I believe everybody involved is of good will and actually shares a common goal of doing the right thing for the web, despite some disagreements on the how.

> But we are still deeply committed to interoperability, IP protection and standards - so I think our fundamental values are well aligned here (we have no desire for Chrome-only APIs long term, as I think you can see in all the efforts around web components, service worker, etc.).  We just have a healthy disagreement around the ideal process to balance the difficult competing goals.

I recognize that. It's in a spirit of shared goals and healthy disagreements that I'm writing.

> The blink launch process <http://www.chromium.org/blink#launch-process> does not provide any provision for "wait to see if we get some more interest or feedback".

No, but it does have <http://www.chromium.org/blink#new-features> “we strive to ensure that the features we ship by default have open standards”.

> But tl;dr is that we fundamentally disagree that a "don't ship any new API until there's a W3C spec at CR status" process would constitute "good citizenship" over the web platform (in fact the opposite - that it caused immeasurable harm to the web's ability to adapt to the mobile world, and before that was responsible for need to form the WHATWG and rewrite HTML from scratch).

It's ok to disagree, but the parenthetical here is factually incorrect.

- The WHATWG was not created as a reaction to a CSSWG policy formalized in 2015 (and loosely agreed to in the year or 2 prior to that). It was established in 2004 as a result of W3C refusing to work on HTML.

- A policy that caused damage to the web was the prefixing policy combined with the habit (mostly Apple's at the time) of ship-first-talk-later, as well as the lack of ability of the CSSWG then to prioritize and make quick progress (improved but not fully fixed since then. More on that later).

- The policy I am talking about was set up as a reaction against that. It was crafted not only to accommodate, but to encourage what Google has also been championing: ship experimental things early behind a flag, work out the fundamentals of the spec, then ship, then refine.

I think the essence of our disagreement is about the best way and place to work out the fundamentals of the spec.

I definitely understand the importance of a minimizing time to market, and that this means you need to reduce friction along the way. But I think in your attempt to do so, you're throwing the baby away with the bathwater.

> Between the first public version of the spec[1] and intent to ship [2], there's just 22 days.
> 
> Actually the spec first landed here <https://github.com/WICG/interventions/commit/6adf80b1802ad2471c2e2c24337b3ef1f40c976f#diff-8cbeb129c0388e3f52dac25ba7333bad> back in July (4 months before i2s) and we started discussing it with other implementors before that (Sydney CSSWG meeting in Feb IIRC?).  That commit just moved it to it's own repo recently as part of trying to follow the correct WICG process.  Sorry that wasn't clear from the commit history.

Even better. 

This spec is such an obviously relevant topic that you'd have had no problem getting an ED in the CSSWG in July had you asked for it, and an FPWD at the same time or shortly after. The CSSWG doesn't normally push back against EDs on relevant topics or FPWD on sane approaches. For such a focused spec, with very little CSS API surface, I don't see any reason it couldn't get to CR or about half a year: FPWD in July, immediate call for horizontal review to the usual suspects (a11y, security, i18n), come out clean (probably), announce intent to go to CR in September, waking up WG members who hadn't paid attention yet... You could be reaching CR about now, and ship without flag in production without having me rant at you.

Why would that be any better than the way you're doing it?

- I wouldn't be ranting at you :-P

- By working out of the WG, you're working outside of the radar of most, and reduce the feedback you get. Not all smart & CSS-savy people are in the CSSWG or following it, but an awful lot are (and I am *not* speaking about myself, in case there's any doubt), including every other browser vendor. And horizontal review triggers feedback from an even broader community.

- Ship first tweak later is exactly how we get into specs that take forever to stabilize, because (1) we now need to take compat into account and (2) why rush now, it's out there anyway. See Transitions, Transforms and Animations (which isn't really fair, as these are much bigger specs, but still).

- Changing behavior once something is used in the wild is harder than doing so before it hits production builds without a flag. By shipping before you get significant agreement from other vendors, you're encouraging others to do the same. We'll get faster to market, but sorting out the interop mess that will ensue take forever. See Transitions, Transforms and Animations.

- By ignoring a policy that was set up with Google to be in line with your process, you're making it easier for everyone else to justify ignoring the policy. Other than our disagreement about the best forum, I think the Blink process is sane and healthy. But not everyone who ignores best practices will be as principled or informed as you are. If you think the policy is bad, please argue for changing it, so that we can keep encouraging everybody to follow a sane and healthy process.

This isn't to say that the CSSWG is or has always been perfect. Some improvements to reduce friction have been made, more are needed.

- Smaller focused specs are good. We're getting better at this, and you can trivially do so for your own specs (which you are doing).

- Wrapping up faster and pushing some details to the next level is good. We're getting better at this, and you can easily push when/if it slows you down.

- The CSSWG needs to increase its bandwidth. Multi-tracks meetings, more offline decisions... We need more of this, and soon. Let's put pressure on the chairs.

- The mechanics of publishing have become simpler, but need to improve further. Let's put pressure on w3m.

But minimizing the chance of getting feedback is the wrong way to minimize friction. I don't think that's what you set out to do, but I do think that's what you're getting.

> This spec has had a grand total of 3 github issues (one from me). This is a far cry from CR.
> 
> If you've got specific concerns about issues that are likely to result in hard-to-solve compat/interop problems down the road then we're happy to delay further.

I don't think you'd need to delay further if you had worked within the CSSWG rather than outside of it, and you'd have got more feedback in the same time frame. And even if you hadn't quite reached CR yet, the policy I pointed to allows for exceptions for pre-CR features that are considered safe by the WG to release for broad use. But “considered safe” implies that it's been considered, so the standardization process needs to have started though.

—Florian