W3C home > Mailing lists > Public > www-style@w3.org > December 2016

Google's incubation-first standards process

From: Rick Byers <rbyers@chromium.org>
Date: Thu, 1 Dec 2016 13:56:40 -0500
Message-ID: <CAFUtAY_nWji3b1niMUQT8Hx3JMg7F_j10UO1txZe8Q4ScYWYQA@mail.gmail.com>
To: Florian Rivoal <florian@rivoal.net>, Alex Russell <slightlyoff@chromium.org>, Chris Wilson <cwilso@chromium.org>
Cc: Steve Kobes <skobes@chromium.org>, CSS public list <www-style@w3.org>
+slightlyoff and cwilso
Changing the subject since this isn't really about scroll anchoring, but
about how the Google web platform team has been approaching almost every
new API we've worked on over the past year - our "incubation first
standards process
<https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/PJ_E04kcFb8>"
policy.

On Thu, Dec 1, 2016 at 11:10 AM, Florian Rivoal <florian@rivoal.net> wrote:

>
> > On Dec 1, 2016, at 09:16, Steve Kobes <skobes@chromium.org> wrote:
> >
> > This is a reminder that the scroll anchoring opt out / exclusion API
> (overflow-anchor) has been proposed at
> >
> > https://github.com/w3c/csswg-drafts/issues/676
> >
> > and is expected to ship in Chrome soon.  Let me know if you have
> feedback or concerns.
>
> Hi,
>
> On the one hand, this proposal seems a good idea, and after a brief review
> of the spec I think it is sane. On the other hand, from a process point of
> view, I am concerned.
>
> The latest position of the CSSWG about how to ship stuff is here:
> https://www.w3.org/TR/CSS/#responsible. TL;DR: don't ship stuff in
> production until the spec is CR.
>
> 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.

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

Here's what's at the top of www.chromium.com/blink:
>    Blink's Mission:
>    To improve the open web through
>    technical innovation and good citizenship
>
> On the same page, there's this:
>   “we strive to ensure that the features we ship by default have open
> standards.”
>
> While Google is doing great on the technical innovation part, I am much
> more worried about the good citizenship part. Using incubation to
> completely bypass the standardization process doesn't sound like good
> citizenship to me. Writing up something in a personal github repo in public
> is better than not writing up anything, but it falls short of being an open
> standards.
>
> I believe the right thing to do would be to hold off shipping, submit this
> to the CSSWG, and get a FPWD. That should be doable in a single teleconf,
> even possibly offline (i.e. less than a week). Then you get wide review,
> and get a CR. Then you ship.


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

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'm always interested to hear counter examples of course
if you can point to places where Google has caused real harm to developers
or users by dropping the ball on standardization and interoperability.  I
think most of CSSWG has seen the real-world interop improvements I've been
driving <https://www.chromium.org/blink/platform-predictability>, and the
feedback I've gotten from other browser vendors - especially Microsoft -
has been very positive.  But we are certainly still far from doing
everything perfectly (as is Microsoft
<https://blogs.windows.com/msedgedev/2016/04/12/a-world-without-passwords-windows-hello-in-microsoft-edge/#3fADtcK26tLEAo2V.97>
)

>From FPWD to CR it's a bit longer, but if the spec is indeed ready with no
> need to change anything, it could still be done within a few months. I know
> that is not instant, but you could have asked for ED/FPWD a month ago, so
> that's not to be blamed on the CSSWG, and that's what it takes to get
> genuine feedback.


> I hope you'll be as good at good citizenship as you are at technical
> innovation.
>
> —Florian
>
> [1] https://github.com/skobes/ScrollAnchoring/commit/
> 47c1960dcbfe076dd3d2de1482690748fba3ffff
> [2] https://groups.google.com/a/chromium.org/forum/#!msg/
> blink-dev/VJmxBRYGVIE/CogbbYWXCAAJ
>
>
>
>
Received on Thursday, 1 December 2016 18:57:38 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 1 December 2016 18:57:38 UTC