Intent to Ship: Stale While Revalidate

[Dave Tapuska]

Contact emails

dtap...@chromium.org

Explainer

Design Doc

Spec

https://tools.ietf.org/html/rfc5861

Tag Review

Tag Review

Summary

Enable handling of stale-while-revalidate in HTTP Cache-Control header allowing the browser cache to return a stale resource while asynchronously revalidating the resource.

We conducted a finch trial and 11-12% of network requests for the hosts were actually stale and returned a response before revalidating it. Overall these resources were very well cached already (81% increased to 82%).

The results show a reduction of FCP by about 2.43% at the 50th percentile, and 2.96% at the 99th percentile.

Link to “Intent to Implement” blink-dev discussion

Intent to Implement

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Risks

Interoperability and Compatibility

This is an optimization of handling of requests so the risk is low that a user would see unintended results.

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: Positive. We have large partners already serving up stale-while-revalidate headers and are excited to see this ship.

Ergonomics

There is some risk since stale while revalidate handling is only for subresource requests and not the main document. This should not cause observable issues to the end user but could be an unexpected result from the web developer.

Secondly there is some risk with Service Workers. The fetch API doesn't have an extension to load a resource with stale revalidation. It does have an API to fetch resources from the cache without any staleness check. So it is possible to implement stale while revalidate handling already today in a service worker but there is no functionality to take advantage of the built in behavior.

Activation

No. Relatively easy to activate. Adjust Cache-Control HTTP Header.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

No. This is an implementation detail of caching behavior not testable in WPT.

Entry on the feature dashboard

https://www.chromestatus.com/feature/5050913014153216

[Josh Matthews]

There are HTTP cache tests present in https://github.com/web-platform-tests/wpt/tree/master/fetch/http-cache; what is it about stale-while-revalidate that makes it unsuitable for automated WPT tests?

cheers,

Josh

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXecWHSnv-Ph3s_CRr9Bc3e_j91xZaFv8dUC13yZnQT5A%40mail.gmail.com.

[Dave Tapuska]

These tests use the fetch API. As highlighted requesting resources via the fetch API doesn't activate the stale-while-revalidate handling in Chrome.

dave.

[Yoav Weiss]

On Mon, Dec 10, 2018 at 7:37 PM Dave Tapuska <dtap...@chromium.org> wrote:

Contact emails

dtap...@chromium.org

Explainer

Design Doc

I like the design, as it makes sure the revalidation requests also have a renderer-based client.

 

Spec

https://tools.ietf.org/html/rfc5861

Tag Review

Tag Review

Summary

Enable handling of stale-while-revalidate in HTTP Cache-Control header allowing the browser cache to return a stale resource while asynchronously revalidating the resource.

We conducted a finch trial and 11-12% of network requests for the hosts were actually stale and returned a response before revalidating it. Overall these resources were very well cached already (81% increased to 82%).

The results show a reduction of FCP by about 2.43% at the 50th percentile, and 2.96% at the 99th percentile.

Impressive! :)

 

Link to “Intent to Implement” blink-dev discussion

Intent to Implement

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes

Risks

Interoperability and Compatibility

This is an optimization of handling of requests so the risk is low that a user would see unintended results.

I think there is some risk in case developers are using it wrong and the content which turns stale is then materially different than the revalidated one. (and out of sync with other resources on the same page)

At the same time, if you heard no complaints on that front during the finch trial, we can assume that the risk is indeed low.

Have you measured if the amount of page reloads increased for the tested group? That would be another way in which users can react to out-of-sync resources.

 

Edge: No signals

Firefox: No signals

Safari: No signals

Web / Framework developers: Positive. We have large partners already serving up stale-while-revalidate headers and are excited to see this ship.

Ergonomics

There is some risk since stale while revalidate handling is only for subresource requests and not the main document. This should not cause observable issues to the end user but could be an unexpected result from the web developer.

Secondly there is some risk with Service Workers. The fetch API doesn't have an extension to load a resource with stale revalidation. It does have an API to fetch resources from the cache without any staleness check. So it is possible to implement stale while revalidate handling already today in a service worker but there is no functionality to take advantage of the built in behavior.

Activation

No. Relatively easy to activate. Adjust Cache-Control HTTP Header.

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

No. This is an implementation detail of caching behavior not testable in WPT.

As it is observable by both servers as well as Resource Timing, I wouldn't consider it an implementation detail. I think this definitely can and should be tested.

 

Entry on the feature dashboard

https://www.chromestatus.com/feature/5050913014153216

--

[PhistucK]

> These tests use the fetch API. As highlighted requesting resources via the fetch API doesn't activate the stale-while-revalidate handling in Chrome.

So fetch(...) (not the fetch event in service workers) implicitly disables stale-while-revalidate handling?

What about XMLHttpRequest?

☆PhistucK

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZWdmNYy4UxKEqEBd8%3DWVv6rOeHNCOq4EsrH5FwmRro-dA%40mail.gmail.com.

[Daniel Bratell]

This seems to be quite ready. Just need to clarify the test situation. WPT tests is what gives us compatible implementations as well as ensuring Chromium's own correct behaviour. Is it WPT not suitable for testing this in some way?

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2BkXJMJ_wiiXw8swm%2B%3Db9LgiKTFx75vr0ChZvum-bVX%3DQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CET (UTC+1) */

[Dave Tapuska]

I'm going to examine wpt tests. For layout tests we use some php code. Not sure if that is doable in the wpt. 

Let's loop back in the new year on this intent. I think I know how I can at least make a pull request in the fetch spec for the functionality we have too.. to get it a little more formal. 

Dave

[Josh Matthews]

WPT supports server-side python: https://wptserve.readthedocs.io/en/latest/

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXND%2B7c7fz62pxvKNH2jorJ_RvZghVEiEC8%2B1o76n%2BCHg%40mail.gmail.com.

[Ben Kelly]

On Mon, Dec 10, 2018 at 1:37 PM Dave Tapuska <dtap...@chromium.org> wrote:

Spec

https://tools.ietf.org/html/rfc5861

Do you have links to other spec discussion or PRs?  The following behavior is not defined in this linked spec document AFAICT:

1. Feature disabled for fetch/xhr

2. Feature exposes additional observable entries in ResourceTiming

3. Interaction (or lack of interaction) with service workers

I just want to make sure other browsers can implement this feature in an inter-operable way without reverse engineering chrome.

Thanks.

Ben

[Dave Tapuska]

A Pull request will be submitted against the fetch spec hopefully this week. Thanks to Josh's hint I've been able to rewrite the layout tests in WPT format here: https://chromium-review.googlesource.com/c/chromium/src/+/1383297 up for review.

dave.

[Josh Matthews]

Thanks! I am pleased to see this feature get the testing that it deserves :)

Cheers,

Josh

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXuNiEY%2B5CB%3DO5qSitLCc3%3D0yqqn0yLkw-E23%3DFrxCW1w%40mail.gmail.com.

[Yoav Weiss]

On Wed, Dec 19, 2018 at 4:38 PM Dave Tapuska <dtap...@chromium.org> wrote:

A Pull request will be submitted against the fetch spec hopefully this week. Thanks to Josh's hint I've been able to rewrite the layout tests in WPT format here: https://chromium-review.googlesource.com/c/chromium/src/+/1383297 up for review.

Looking at the tests, I see that you're excluding fetch() from SwR. Would that be the same in your Fetch PR? Could you expand on why that that kind of special-casing is required? Does that special-casing apply to all the requests with of the same destination? (e.g. XHR, beacon)

 

dave.

On Wed, Dec 19, 2018 at 10:33 AM Ben Kelly <wande...@chromium.org> wrote:

On Mon, Dec 10, 2018 at 1:37 PM Dave Tapuska <dtap...@chromium.org> wrote:

Spec

https://tools.ietf.org/html/rfc5861

Do you have links to other spec discussion or PRs?  The following behavior is not defined in this linked spec document AFAICT:

1. Feature disabled for fetch/xhr

2. Feature exposes additional observable entries in ResourceTiming

3. Interaction (or lack of interaction) with service workers

I just want to make sure other browsers can implement this feature in an inter-operable way without reverse engineering chrome.

Thanks.

Ben

--

[Dave Tapuska]

The PR against the fetch spec is here. My intention is to hook the html spec that delegates to the fetch spec indicating the cache-mode is "stale-while-revalidated" for specific cases. Does that answer your question?

dave.

[Yoav Weiss]

On Tue, Jan 15, 2019 at 6:17 PM Dave Tapuska <dtap...@chromium.org> wrote:

The PR against the fetch spec is here. My intention is to hook the html spec that delegates to the fetch spec indicating the cache-mode is "stale-while-revalidated" for specific cases. Does that answer your question?

You're pointing towards an issue, rather than a PR, but I'm guessing you were referring to the commit on your branch?

In that commit, I see that it's defining a new "async-stale-revalidated" cache mode, and what happens when it is set. IIUC, you'd then set that flag in various places in HTML. Is that correct?

Can you elaborate on which cases the flag will or will not be set and why? Are there any blockers to defining the use of that flag in HTML?

[Dave Tapuska]

Yes I'm referring to the commit.

>In that commit

Yes you are correct in what I was trying to do. If you have alternate suggestions please provide them.

>Can you elaborate on which cases the flag

In Chrome we currently are allowing only GETs, that aren't the following resource types:

  return type == ResourceType::kMainResource || type == ResourceType::kRaw ||
         type == ResourceType::kTextTrack || type == ResourceType::kAudio ||
         type == ResourceType::kVideo || type == ResourceType::kManifest ||
         type == ResourceType::kImportResource;
So that essentially means all fetches that aren't the main document, audio, video, import resource loads, preconnects, downloads.  Do you have an alternate way I can make this simpler? I imagine it will be difficult to articulate in the HTML spec.

dave.

[Yoav Weiss]

On Thu, Jan 17, 2019 at 7:16 PM Dave Tapuska <dtap...@chromium.org> wrote:

Yes I'm referring to the commit.

>In that commit

Yes you are correct in what I was trying to do. If you have alternate suggestions please provide them.

>Can you elaborate on which cases the flag

In Chrome we currently are allowing only GETs, that aren't the following resource types:

  return type == ResourceType::kMainResource || type == ResourceType::kRaw ||
         type == ResourceType::kTextTrack || type == ResourceType::kAudio ||
         type == ResourceType::kVideo || type == ResourceType::kManifest ||
         type == ResourceType::kImportResource;
So that essentially means all fetches that aren't the main document, audio, video, import resource loads, preconnects, downloads.  Do you have an alternate way I can make this simpler? I imagine it will be difficult to articulate in the HTML spec.

I think you can set the flag based on request destination and method somewhere as part of the Fetch spec fetching section, rather than try to modify all the potential callers.

I'm still wondering regarding the reasoning.

Looking at the code, it seems like you're using `IsRawResource` for this, with the following comment:

  // Indicate whether the network stack can return a stale resource. If a
  // stale resource is returned a StaleRevalidation request will be scheduled.
  // Explicitly disallow stale responses for fetchers that don't have SWR
  // enabled (via origin trial), non-GET requests and resource requests that
  // are raw. We are explicitly excluding RawResources here to avoid
  // unintentional SWR, as bugs around RawResources tend to be complicated and
  // critical.

It would be good to detail the reasoning here, ideally in a GH issue on the Fetch spec and/or in a spec note close to where the flag will be set.

[Dave Tapuska]

Yoav,

I've revised the pull request based on your feedback.

dave.

[Dave Tapuska]

Any more comments on this? The WPT tests that I wrote were merged last week and there are no comments on the latest version of the pull request.

dave.

[Kinuko Yasuda]

Hi Dave,

I think this is generally looking good, but I'm still a bit concerned about interaction with Service Workers (which is currently being discussed on PR), and also that the proposed spec change in the PR looks to be a bit biased by the current implementation gotchas.

For example afair the Raw Resource limitation was originally introduced mainly to avoid undesirable implementation gotchas that are specific to Chrome to make it easier for us to have initial iteration results, while I don't think we were fully sure if such limitation should be also introduced as a spec text.  Looking back this limitations now I feel it could actually make sense, but I didn't see the enough reasoning was given (e.g. about the ) on the PR.  I think it could be helpful if you clarify the potential differences (if any) between the current impl and ideal spec text here and maybe also on github.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZXhtNdnHqp%2BDBEOkB-yE19ur1EpRgQkPKdzpCEchrQWVg%40mail.gmail.com.

[Dave Tapuska]

I've updated the PR to indicate safe subresource requests. I think this helps clarify the requests that we are after.

SW = Service Worker

SWR = Stale While Revalidate

There is debate on the github issue about letting SW know about the SWR requests and I don't believe this is necessary at this time. SWs aren't given stale responses (ie. if they addAll or fetch, these are unsafe resource requests so they won't get stale responses in the proposed spec). It would be possible to augment the specification in the future to add support for SWs to know about requesting and handling stale responses. This would need to be explicitly done since we can't do it implicitly as it would create interop issues, so I don't believe there is need to do it right now.

What else can I do to get this Intent To Ship progressing?

dave.

[Philip Jägenstedt]

Thanks for taking care of the WPT situation, Dave! Looks like they landed in https://github.com/web-platform-tests/wpt/pull/15047 and results are on wpt.fyi. I've sent https://github.com/web-platform-tests/wpt/pull/15350 to fix a problem, but more important that the failure mode is whether these tests are already expected to pass with experimental flags enabled? If they are, can you check why they do fail? (Possibly a Chrome-vs-content_shell problem given that the Chromium CL didn't have failing expectations?)

Typically an Intent to Ship is allowed to be blocked on the spec change being merged. Is https://github.com/whatwg/fetch/pull/853 the only outstanding spec change for this, and who is it blocked on now?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZWSEpeytjYDJRZNPXc4XcFQLTpYybB%3DR2PPiD-WME054w%40mail.gmail.com.

[Kinuko Yasuda]

The spec PR https://github.com/whatwg/fetch/pull/853 looks to be in a good shape now (Philip: yes that's the only outstanding spec change in my understanding), most of limitations derived from the current implementation gotchas seem to be just removed from the spec text, and it has clearer texts about HTTP cache interactions.

Overall I'm happy with this.  Non-owner LGTM

[Yoav Weiss]

Thanks Kinuko! From my perspective, the PR looks good as well.

Dave - have you also enabled support for this for raw resources? Or are there still implementation issues there? 

[Kinuko Yasuda]

For raw resources-- Dave uploaded a patch and it's in my review queue :)

However corresponding tests have been already added (with a bug and failure expectations) so that the spec/impl diff is pretty clear now.

 

2019年3月8日(金) 18:42 Yoav Weiss <yo...@yoav.ws>:

[Yoav Weiss]

In that case, LGTM1 once that patch lands and we align with the spec/tests.

[Chris Harrelson]

LGTM2 with same caveats.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEiDdvCeZeOkN3SNA6C2WSJ5CujfLW%3DxZTdMCHFw33BcMg%40mail.gmail.com.

[Dave Tapuska]

Yoav, Chris: are your LGTMs dependant on the PR for the spec landing? In order to land the PR we need another browser vendor to commit to it. Anne has opened up a Mozilla standards position but I wanted you to clarify if you are happy with the PR as this. Or whether I should maintain a fork the fetch spec.

Kinuko has reviewed the implementation change and now our implementation matches the spec and tests.

dave.

[Chris Harrelson]

Hi Dave, Thanks for your patience and great work getting this done. I agree that it's not strictly necessary for the PR to land, for the reason you mentioned. The situation with policy about when it's ok to land spec changes in HTML is not so good, this needs to improve somehow. But that's not on you, so it should not block your feature.

Can you confirm that there is consensus on the PR that it's correct, and that it matches the implementation and testing situation? If so, then you have my LGTM.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZW4M7nvNY081DyZwMZkpteojG8-NwJA4VBWEqR%3DOpGtOA%40mail.gmail.com.

[Dave Tapuska]

Yes there is consensus on the PR (from the people that have chimed commented thus far). Anne asked to me to make some editorial changes to it today and those are now done. The Chrome implementation matches the specification & tests.

dave.

[Chris Harrelson]

Sounds great! Thanks again.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHgVhZVbLNnOri%3Dusc9iH-od1Woq4GSugVBh90hxtxNL1xHRQw%40mail.gmail.com.

[Anne van Kesteren]

On Tue, Mar 12, 2019 at 7:28 PM Chris Harrelson <chri...@chromium.org> wrote:
> The situation with policy about when it's ok to land spec changes in HTML is not so good, this needs to improve somehow.

This isn't HTML, it's Fetch, though the same policy applies to both.
What's not good about it? It seems to me that if there's no two
implementations it's not really a standard. (And the bar is lower than
that, only need interest.)

[Yoav Weiss]

Thanks for pushing this through! Still LGTM without blocking on the PR landing

[Yoav Weiss]

I agree with that general sentiment.

However, the current situation where shipping features are backed by PRs is not ideal:

• It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.
• It makes it hard for reviewers to understand where a feature currently stands
• One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.
• Other specifications (e.g. SXG loading) seem to be going down a similar path ( +Jeffrey Yasskin for Opinions™)

Also, let's talk about the elephant in the room while we're at it. With Edge/Chromium, is the assumption that it will no longer count as a separate implementation?

If so, that implicitly raises the bar, and makes sure that the above situation takes longer to resolve.

I keep wondering if we cannot somehow resolve the above inconveniences through technical means, without requiring any policy changes. (e.g. better/annotated PR previews)

Alternatively, if monkey-patching is an inevitable intermediate step when working on features that are destined for WHATWG specs, maybe there are ways to make them easier/clearer?

Cheers,

Yoav

[Anne van Kesteren]

On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.

I'm not sure I understand this.

> It makes it hard for reviewers to understand where a feature currently stands

Which reviewers? As far as standards are concerned, it's very similar
to v0 Web Components I'd say.

> One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.

Yeah, the Client Hints situation hasn't been great. It was somehow
"done" without end-to-end integration.

> Also, let's talk about the elephant in the room while we're at it. With Edge/Chromium, is the assumption that it will no longer count as a separate implementation?

I think the elephant in the room is that Chrome is moving ahead with
things despite not having buy-in from others, reminiscent of the
Netscape days. Seems rather clear that Microsoft using the same engine
as Google would not count as a distinct implementation.

[Philip Jägenstedt]

Anne, Dave, do you have any hunches about whether second implementer interest is likely to materialize shortly?

If that doesn't seem likely, what should we link to in chromestatus.com and eventually MDN? https://www.chromestatus.com/feature/5050913014153216 now links only to https://tools.ietf.org/html/rfc5861, but are the Fetch changes ones that should be linked as well? https://whatpr.org/fetch/853.html#concept-stale-while-revalidate-response works, but another option would be to publish a fork of the spec.

LGTM3 to ship assuming some stable spec URL to refer to.

[Yoav Weiss]

On Wed, Mar 13, 2019 at 10:40 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.

I'm not sure I understand this.

A single feature is typically worked on over multiple months, with multiple contributors. If we want all that feature work to live in a single PR until another implementation shows interest, it means that when that work will get merged, that history will likely not be reflected in the final spec's revision control.

  

> It makes it hard for reviewers to understand where a feature currently stands

Which reviewers?

Browser engineers and browser vendors, as well as web developers interested in the feature. They need a convenient way to evaluate where the feature is (in the case of other vendors, in order to get their support), and right now, that's a challenge.

[PhistucK]

See my comments inline.

☆PhistucK

On Wed, Mar 13, 2019 at 12:34 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Mar 13, 2019 at 10:40 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.

I'm not sure I understand this.

A single feature is typically worked on over multiple months, with multiple contributors. If we want all that feature work to live in a single PR until another implementation shows interest, it means that when that work will get merged, that history will likely not be reflected in the final spec's revision control.

  

> It makes it hard for reviewers to understand where a feature currently stands

Which reviewers?

Browser engineers and browser vendors, as well as web developers interested in the feature. They need a convenient way to evaluate where the feature is (in the case of other vendors, in order to get their support), and right now, that's a challenge.

How does having those in the specification itself (when they do not yet have the buy-in from others) make things any clearer? Or do you have other alternatives in mind?

 

As far as standards are concerned, it's very similar
to v0 Web Components I'd say.


> One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.

Yeah, the Client Hints situation hasn't been great. It was somehow
"done" without end-to-end integration.


> Also, let's talk about the elephant in the room while we're at it. With Edge/Chromium, is the assumption that it will no longer count as a separate implementation?

I think the elephant in the room is that Chrome is moving ahead with
things despite not having buy-in from others, reminiscent of the
Netscape days. Seems rather clear that Microsoft using the same engine
as Google would not count as a distinct implementation.

--

You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgnqPedAdOoq4DFJU3hzpzTrrz7oVYXStVJ8NQVLzRPbg%40mail.gmail.com.

[Philip Jägenstedt]

I wasn't around to see the shipping process in the Netscape days, but the bar for shipping new features in Blink is quite high in terms of work required. In order to make it as easy as possible for other vendors to implement and ship, we ask for a spec and test suite that matches the implementation. By contrast, lots of stuff shipped in the Netscape/IE is called DOM appeared to have unspec'd and untested, leaving that for decades later.

We rely on the code review process for spec and test quality, just like for the implementation. I'm sure you'd be able to find exceptions, but when I've taken a deep dive on an intent both spec and tests tend to be there by the time the intent has 3xLGTM.

However, while we ask about interest from other vendors and should try to secure it, we ultimately don't block on that interest being there. Sometimes it's just not a priority, and even more rarely there might be opposition to a feature which nonetheless seems important enough to ship. AFAICT, no browse vendor has ever had a policy of only shipping things with a second implementation secured.

Anne, what does Mozilla do when you want to ship something and nobody else is as keen? What do you think  the Blink process should be for cases like this? (There are plenty of Firefox-only APIs, but looking at ones added in the last year it's not clear if any of them are such cases. Chrome's equivalent list is much longer.)

I agree that it doesn't make sense to count Chromium-based browsers separately, either in the WHATWG criteria or in the Blink launch process.

[Jeffrey Yasskin]

On Wed, Mar 13, 2019 at 2:23 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Mar 13, 2019 at 9:38 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Mar 12, 2019 at 7:28 PM Chris Harrelson <chri...@chromium.org> wrote:
> The situation with policy about when it's ok to land spec changes in HTML is not so good, this needs to improve somehow.

This isn't HTML, it's Fetch, though the same policy applies to both.
What's not good about it? It seems to me that if there's no two
implementations it's not really a standard. (And the bar is lower than
that, only need interest.)

I agree with that general sentiment.

However, the current situation where shipping features are backed by PRs is not ideal:

• It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.
• It makes it hard for reviewers to understand where a feature currently stands
• One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.
• Other specifications (e.g. SXG loading) seem to be going down a similar path ( +Jeffrey Yasskin for Opinions™)

So far, I like the approach SXG loading is taking, and I think I'd like it even if we'd decided to block shipping on Mozilla or Apple deciding the feature is a good idea. Specifically, living in a document lets us do code reviews on changes to that document, which lets us at least ask if changes to the proposal make Mozilla and Apple incrementally happier. Having the proposal live in a PR wouldn't give them that ability to comment on or see changes.

There's always going to be a speed bump in tracking history across the actual merge: for a separate document, people have to find the original repository and annotate there. For a PR, the PR author has to do a lot of extra work to keep the sequence of changes meaningful across merges from (or rebases onto) the main spec, and the merge has to either happen as a merge, or the person trying to search the history has to jump over to Github. So I don't feel like the question of how much history is preserved really helps decide between these options.

Jeffrey

[Dave Tapuska]

I chatted briefly with a firefox engineer today on IRC and they will bring it up with their necko team tomorrow. Chrome status has been updated to point at the PR.

dave.

[Philip Jägenstedt]

On Wed, Mar 13, 2019 at 6:56 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:

On Wed, Mar 13, 2019 at 2:23 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Wed, Mar 13, 2019 at 9:38 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Tue, Mar 12, 2019 at 7:28 PM Chris Harrelson <chri...@chromium.org> wrote:
> The situation with policy about when it's ok to land spec changes in HTML is not so good, this needs to improve somehow.

This isn't HTML, it's Fetch, though the same policy applies to both.
What's not good about it? It seems to me that if there's no two
implementations it's not really a standard. (And the bar is lower than
that, only need interest.)

I agree with that general sentiment.

However, the current situation where shipping features are backed by PRs is not ideal:

• It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.
• It makes it hard for reviewers to understand where a feature currently stands
• One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.
• Other specifications (e.g. SXG loading) seem to be going down a similar path ( +Jeffrey Yasskin for Opinions™)

So far, I like the approach SXG loading is taking, and I think I'd like it even if we'd decided to block shipping on Mozilla or Apple deciding the feature is a good idea. Specifically, living in a document lets us do code reviews on changes to that document, which lets us at least ask if changes to the proposal make Mozilla and Apple incrementally happier. Having the proposal live in a PR wouldn't give them that ability to comment on or see changes.

There's always going to be a speed bump in tracking history across the actual merge: for a separate document, people have to find the original repository and annotate there. For a PR, the PR author has to do a lot of extra work to keep the sequence of changes meaningful across merges from (or rebases onto) the main spec, and the merge has to either happen as a merge, or the person trying to search the history has to jump over to Github. So I don't feel like the question of how much history is preserved really helps decide between these options.

Yeah, writing the diff out in prose as "after step N add these steps" does make it easier to maintain as a separate document. It does mean that conflicts aren't necessarily noticed, but a long-lived branch in the spec repo itself might instead get more spurious conflicts to resolve over time.

In the case that something starts out as a PR against an existing spec and in the end there's not enough implementer interest to merge it, I think it might make sense to leave it as an open PR though, if the PR author doesn't think it's helpful to convert it into monkey patch style.

Silly idea: maybe one could generate monkey patch style from a real patch?

[Philip Jägenstedt]

On Wed, Mar 13, 2019 at 12:26 PM Philip Jägenstedt <foo...@chromium.org> wrote:

On Wed, Mar 13, 2019 at 10:40 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.

I'm not sure I understand this.


> It makes it hard for reviewers to understand where a feature currently stands

Which reviewers? As far as standards are concerned, it's very similar
to v0 Web Components I'd say.


> One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.

Yeah, the Client Hints situation hasn't been great. It was somehow
"done" without end-to-end integration.


> Also, let's talk about the elephant in the room while we're at it. With Edge/Chromium, is the assumption that it will no longer count as a separate implementation?

I think the elephant in the room is that Chrome is moving ahead with
things despite not having buy-in from others, reminiscent of the
Netscape days. Seems rather clear that Microsoft using the same engine
as Google would not count as a distinct implementation.

I wasn't around to see the shipping process in the Netscape days, but the bar for shipping new features in Blink is quite high in terms of work required. In order to make it as easy as possible for other vendors to implement and ship, we ask for a spec and test suite that matches the implementation. By contrast, lots of stuff shipped in the Netscape/IE is called DOM appeared to have unspec'd and untested, leaving that for decades later.

We rely on the code review process for spec and test quality, just like for the implementation. I'm sure you'd be able to find exceptions, but when I've taken a deep dive on an intent both spec and tests tend to be there by the time the intent has 3xLGTM.

After kind off-list feedback I want to walk this back a bit. While it's not possible to get test or implementation changes merged without review, there's no such requirement in place for getting things published at w3c.github.io or wicg.github.io URLs. I don't have any stats, but it would be possible to just push to master and self-review PRs all the way. You can also get yourself a whatpr.org URL without anyone actually having reviewed it.

This is something that +Domenic Denicola, +Johnny Stenback and I have been discussing a bit lately. At a technical level what would be required is branch protection with required review for all spec repos, and maybe a review step for moving repos into certain GitHub orgs.

Ensuring a certain level of review is a harder problem, and just like with test and implementation review I don't think there could be a technical solution, it's rather a shared expectation.

+Anne van Kesteren +Boris Zbarsky, how are you approaching spec review and spec quality at Mozilla when you're working on an entirely new thing? I couldn't think of a quick way to filter specs by editor affiliation, do you have examples to share?

[Yoav Weiss]

On Thu, Mar 14, 2019 at 11:29 AM Philip Jägenstedt <foo...@chromium.org> wrote:

On Wed, Mar 13, 2019 at 12:26 PM Philip Jägenstedt <foo...@chromium.org> wrote:

On Wed, Mar 13, 2019 at 10:40 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.

I'm not sure I understand this.


> It makes it hard for reviewers to understand where a feature currently stands

Which reviewers? As far as standards are concerned, it's very similar
to v0 Web Components I'd say.


> One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.

Yeah, the Client Hints situation hasn't been great. It was somehow
"done" without end-to-end integration.


> Also, let's talk about the elephant in the room while we're at it. With Edge/Chromium, is the assumption that it will no longer count as a separate implementation?

I think the elephant in the room is that Chrome is moving ahead with
things despite not having buy-in from others, reminiscent of the
Netscape days. Seems rather clear that Microsoft using the same engine
as Google would not count as a distinct implementation.

I wasn't around to see the shipping process in the Netscape days, but the bar for shipping new features in Blink is quite high in terms of work required. In order to make it as easy as possible for other vendors to implement and ship, we ask for a spec and test suite that matches the implementation. By contrast, lots of stuff shipped in the Netscape/IE is called DOM appeared to have unspec'd and untested, leaving that for decades later.

We rely on the code review process for spec and test quality, just like for the implementation. I'm sure you'd be able to find exceptions, but when I've taken a deep dive on an intent both spec and tests tend to be there by the time the intent has 3xLGTM.

After kind off-list feedback I want to walk this back a bit. While it's not possible to get test or implementation changes merged without review, there's no such requirement in place for getting things published at w3c.github.io

That depends on the WG, ATM. Maybe the W3C can impose that as a general rule for all WGs? 

or wicg.github.io URLs.

 

I think we can impose PR review as a rule in the CG, by fellow editors. 

OTOH, at least at the moment, having a document live on the WICG org does not automatically give it extra authoritativeness, other than indicate that there was some industry interest in resolving that problem.

Are we interested in changing that?

+Marcos Caceres +Chris Wilson for their opinions.

I don't have any stats, but it would be possible to just push to master and self-review PRs all the way. You can also get yourself a whatpr.org URL without anyone actually having reviewed it.

This is something that +Domenic Denicola, +Johnny Stenback and I have been discussing a bit lately. At a technical level what would be required is branch protection with required review for all spec repos, and maybe a review step for moving repos into certain GitHub orgs.

Yeah, if we enforce reviews as part of the WICG GH org, we'd need a review step when importing incubated work from external repos. It's not clear who will conduct those reviews though.

[Philip Jägenstedt]

On Thu, Mar 14, 2019 at 11:43 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Mar 14, 2019 at 11:29 AM Philip Jägenstedt <foo...@chromium.org> wrote:

On Wed, Mar 13, 2019 at 12:26 PM Philip Jägenstedt <foo...@chromium.org> wrote:

On Wed, Mar 13, 2019 at 10:40 AM Anne van Kesteren <ann...@annevk.nl> wrote:

On Wed, Mar 13, 2019 at 10:23 AM Yoav Weiss <yo...@yoav.ws> wrote:
> It makes it harder to keep track of the feature's evolution and have reasonable source control for it once it lands, as PRs typically tend to get squashed.

I'm not sure I understand this.


> It makes it hard for reviewers to understand where a feature currently stands

Which reviewers? As far as standards are concerned, it's very similar
to v0 Web Components I'd say.


> One example of that: I'm currently working on Client Hints, did a bunch of work of unifying multiple PRs from multiple people into a single Fetch PR, and I'm still getting complaints that the state of the feature is currently not clear, as reviewers need to look at a couple of PRs (on Fetch and HTML) to understand the situation. Now I have a task on my plate to create a separate document that will monkey patch those specifications, to make it clearer for folks where things are and where the feature is going.

Yeah, the Client Hints situation hasn't been great. It was somehow
"done" without end-to-end integration.


> Also, let's talk about the elephant in the room while we're at it. With Edge/Chromium, is the assumption that it will no longer count as a separate implementation?

I think the elephant in the room is that Chrome is moving ahead with
things despite not having buy-in from others, reminiscent of the
Netscape days. Seems rather clear that Microsoft using the same engine
as Google would not count as a distinct implementation.

I wasn't around to see the shipping process in the Netscape days, but the bar for shipping new features in Blink is quite high in terms of work required. In order to make it as easy as possible for other vendors to implement and ship, we ask for a spec and test suite that matches the implementation. By contrast, lots of stuff shipped in the Netscape/IE is called DOM appeared to have unspec'd and untested, leaving that for decades later.

We rely on the code review process for spec and test quality, just like for the implementation. I'm sure you'd be able to find exceptions, but when I've taken a deep dive on an intent both spec and tests tend to be there by the time the intent has 3xLGTM.

After kind off-list feedback I want to walk this back a bit. While it's not possible to get test or implementation changes merged without review, there's no such requirement in place for getting things published at w3c.github.io

That depends on the WG, ATM. Maybe the W3C can impose that as a general rule for all WGs? 

I've reach out to plh about that idea.

 

or wicg.github.io URLs.

 

I think we can impose PR review as a rule in the CG, by fellow editors. 

OTOH, at least at the moment, having a document live on the WICG org does not automatically give it extra authoritativeness, other than indicate that there was some industry interest in resolving that problem.

Are we interested in changing that?

+Marcos Caceres +Chris Wilson for their opinions.

If authoritativeness means multi-vendor buy-in then that is a separate dimension to whether or not code review has happened.

I think it could be a good idea to require review at a technical level, but I'd certainly want to survey the people who have pushed commits to WICG repos over the last year to see if that would have unexpected downsides. Yoav, are you interested in exploring this?

I don't have any stats, but it would be possible to just push to master and self-review PRs all the way. You can also get yourself a whatpr.org URL without anyone actually having reviewed it.

This is something that +Domenic Denicola, +Johnny Stenback and I have been discussing a bit lately. At a technical level what would be required is branch protection with required review for all spec repos, and maybe a review step for moving repos into certain GitHub orgs.

Yeah, if we enforce reviews as part of the WICG GH org, we'd need a review step when importing incubated work from external repos. It's not clear who will conduct those reviews though.

Right, this is inevitably the hard part: reviewing specs carefully as a would-be implementer is incredibly time consuming.

[Emilio Cobos Álvarez]

On 13/03/2019 12:26, Philip Jägenstedt wrote:
> On Wed, Mar 13, 2019 at 10:40 AM Anne van Kesteren <ann...@annevk.nl

> (There are plenty of Firefox-only APIs, but looking at
> ones added in the last year

> <http://web-confluence.appspot.com/#!/catalog?releases=%5B%22Firefox_58.0_Windows_10.0%22,%22Safari_12.0_OSX_10.14%22,%22Edge_18.17763_Windows_10.0%22,%22Chrome_71.0.3578.80_Windows_10.0%22,%22Firefox_64.0_Windows_10.0%22%5D&q=%22notin:firefox58%20in:firefox64%20count:1%22>

> it's not clear if any of them are such cases. Chrome's equivalent list

> <http://web-confluence.appspot.com/#!/catalog?releases=%5B%22Chrome_63.0.3239.84_Windows_10.0%22,%22Safari_12.0_OSX_10.14%22,%22Edge_18.17763_Windows_10.0%22,%22Chrome_71.0.3578.80_Windows_10.0%22,%22Firefox_64.0_Windows_10.0%22%5D&q=%22notin:chrome63%20in:chrome71%20count:1%22>
> is much longer.)

FWIW, the ShadowRoot ones looks like it comes from our initial v0
implementation, and slipped in when shipping v1, will remove [1].

I don't know about the SVG ones, but AFAIK we haven't shipped any
WebAnimations or CSS bits that other people have objected to / seen as
harmful, or didn't plan implementing (indeed Blink has implementations
of a few behind a flag IIRC).

-- Emilio

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1535438

> --
> You received this message because you are subscribed to the Google
> Groups "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to blink-dev+...@chromium.org

> <mailto:blink-dev+...@chromium.org>.

> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYe70igLGH8%3DBEj7qrToXrwO%3DsSmJzEfrHTaL9HBi91uBA%40mail.gmail.com
> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYe70igLGH8%3DBEj7qrToXrwO%3DsSmJzEfrHTaL9HBi91uBA%40mail.gmail.com?utm_medium=email&utm_source=footer>.

[Yoav Weiss]

Maybe authoritativeness is not the right word. What I meant is that the fact that a spec is on the WICG org does not (at the moment) provide any quality guarantees about it being "ready" or "in good shape". Requiring reviews will definitely help in going towards that a "better shape" goal (which seems desirable). At the same time, I'm not sure we want to require every commit along the way to make perfect sense and be "ready".

 

I think it could be a good idea to require review at a technical level, but I'd certainly want to survey the people who have pushed commits to WICG repos over the last year to see if that would have unexpected downsides. Yoav, are you interested in exploring this?

I could definitely take that on. It would have to wait until after BlinkOn though.

[Anne van Kesteren]

On Wed, Mar 13, 2019 at 10:52 AM Philip Jägenstedt <foo...@chromium.org> wrote:
> Anne, Dave, do you have any hunches about whether second implementer interest is likely to materialize shortly?

I don't know, but I filed
https://github.com/mozilla/standards-positions/issues/144 to track it
for Mozilla.

[Chris Harrelson]

Right, sorry, Fetch. Also, I agree that interest from a second implementer is a reasonable bar for putting things in the official living spec.

I do think though that there needs to be best-practice solution for committing patches that are not at that stage yet. Otherwise it's hard to do collaboration, breaking into multiple PRs, merging, etc.

 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADnb78g1Qdh%3Da7ZoyBKrRQQehz_jT2J7SdFy1icK%3DkquSFv0aA%40mail.gmail.com.

[Marcos Caceres]

> On Mar 14, 2019, at 9:43 PM, Yoav Weiss <yo...@yoav.ws> wrote:
>
>
> or wicg.github.io URLs.
>
> I think we can impose PR review as a rule in the CG, by fellow editors.
> OTOH, at least at the moment, having a document live on the WICG org does not automatically give it extra authoritativeness, other than indicate that there was some industry interest in resolving that problem.
> Are we interested in changing that?
>
> +Marcos Caceres +Chris Wilson for their opinions.

In WebApps WG, I'm trying to enforce this via this template:

https://github.com/w3c/screen-orientation/blob/gh-pages/.github/PULL_REQUEST_TEMPLATE.md

Core is:

```
The following tasks have been completed:

• Modified Web platform tests (link to pull request)

Implementation commitment:

• WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)
```

We should do the same for all WICG repositories.

> I don't have any stats, but it would be possible to just push to master and self-review PRs all the way. You can also get yourself a whatpr.org URL without anyone actually having reviewed it.
>
> This is something that +Domenic Denicola, +Johnny Stenback and I have been discussing a bit lately. At a technical level what would be required is branch protection with required review for all spec repos, and maybe a review step for moving repos into certain GitHub orgs.
>
> Yeah, if we enforce reviews as part of the WICG GH org, we'd need a review step when importing incubated work from external repos. It's not clear who will conduct those reviews though.

Agree... but I think that's ok. It's not a technical problem: it's a culture we need to build. Accepting a draft just gets a whole bunch of bugs filed on it. Alternatively, the initial spec gets removed and put back together with pull requests in pieces that have consensus... there is lots of different ways of going about this.

> Ensuring a certain level of review is a harder problem, and just like with test and implementation review I don't think there could be a technical solution, it's rather a shared expectation.

Agree.

[Marcos Caceres]

> On Mar 15, 2019, at 8:27 AM, Yoav Weiss <yo...@yoav.ws> wrote:
>
>
> +Marcos Caceres +Chris Wilson for their opinions.
>
> If authoritativeness means multi-vendor buy-in then that is a separate dimension to whether or not code review has happened.
>
> Maybe authoritativeness is not the right word. What I meant is that the fact that a spec is on the WICG org does not (at the moment) provide any quality guarantees about it being "ready" or "in good shape". Requiring reviews will definitely help in going towards that a "better shape" goal (which seems desirable). At the same time, I'm not sure we want to require every commit along the way to make perfect sense and be "ready".

Agree. This is hard... it's in conflict with the principle of "fail fast" and incubation. The whole point is to make things light weight and to pitch ideas... alternatively, at the other extreme of the spectrum: we ditch the idea of doing specs at the WICG, and only do explainers and prototypes: If the explainer/prototype excites people, then we can get more serious about doing a real specs with a proper QA and review process in the W3C or WHATWG.

Just throwing that out there as a straw-person.

[flo...@rivoal.net]

On Tuesday, March 19, 2019 at 3:03:17 PM UTC+9, Marcos Caceres wrote:

In WebApps WG, I'm trying to enforce this via this template:

https://github.com/w3c/screen-orientation/blob/gh-pages/.github/PULL_REQUEST_TEMPLATE.md

Core is:

```
The following tasks have been completed:

        •  Modified Web platform tests (link to pull request)

Implementation commitment:

        •  WebKit (https://bugs.webkit.org/show_bug.cgi?id=)
        •  Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
        •  Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)
```

We should do the same for all WICG repositories.

Writing tests is good, and people should do it. However, making test work an absolute requirement that can block spec work even when there is otherwise agreement is expensive, and will bias in favor of players with abundant resources. In late stages of standardization of things that are meant to be implemented by browsers, this maybe OK. In early incubation, it sounds stifling.

As for implementation commitments, it is always a good thing to monitor and document. But here as well I would advice caution: Different companies have different policy, and although that may change, Apple has historically been extremely reluctant about making public comments about about what they may or may not ship, as they consider their product roadmap to be a valuable secret. This means that a policy that requires public commitments will bias against the technologies that they support. Here as well, the effect is more pronounced in early stages discussions. This does not sound desirable.

—Florian

[flo...@rivoal.net]

On Tuesday, March 19, 2019 at 3:10:17 PM UTC+9, Marcos Caceres wrote:

 At the other extreme of the spectrum: we ditch the idea of doing specs at the WICG, and only do explainers and prototypes: If the explainer/prototype excites people, then we can get more serious about doing a real specs with a proper QA and review process in the W3C or WHATWG.

Just throwing that out there as a straw-person.

This would remove a problem that we have with specifications that are incubated outside of their eventual WG, where most of the people who will provide detailed review aren't involved in the incubation (and maybe even fail to notice it), and thus fail to voice concerns until quite late into the design/implementation process, when they can be already hard to fix.

Between the point where the WG starts an ED and publishes FPWD (at least on the W3C side, I'm less sure about the WHATWG), that would still still be room for a phase where we are still trying to confirm that the approach taken by the particular solution is appropriate even though we are past the point where we confirm that the problem is worth solving.

This would give something like a 3 phase incubation:

1. (possibly in WICG's discuss): try to rally people around solving your problem

2. (possibly in a WICG repo): write an explainer (possibly while prototyping) to define your particular approach to solving the problem

3. Start an ED in the right WG to start nailing down the details

=> when enough people are convinced this is the right approach (this may include statements of implementation interest / commitments), move to FPWD, signaling the end of incubation and the start of maturation

The start of phase 3 would be a little expensive though in the case where a new WG needs to be formed. For those case, starting the spec in a CG seems much easier and to better allow for "fail fast".

—Florian