Hi Ari, The documented process <https://www.chromium.org/blink/launching-features/#new-feature-prepare-to-ship> is to land features and specs before requesting approval to ship, as that gives the best possible chance for wide review and eventual interop. But we unfortunately often find ourselves in the position that this is impractical - eg. spec work blocked from landing due to lack of interest from a 2nd implementor (WHATWG venue) or just very slow reviews. So, if necessary, we are willing to approve based on a PR only but it's usually considered an exceptional situation. None of those seem to be the case here, it's just blocked on some impl and spec work right? In particular, we definitely want to see WPTs landed prior to shipping, so we're aligned with Noam on that request. chrishtr, foolip, yoav and I just discussed this now in the API owners meeting and are aligned on this being standard practice (though wouldn't be surprised if we've slipped up occasionally).
Thanks, Rick On Wed, Apr 19, 2023 at 11:34 AM Ari Chivukula <aric...@chromium.org> wrote: > That differs from my past experience (in which a proposed spec change is > sufficient to move forward with a launch), but if you want me to build and > test it all behind a flag before I get the go ahead here that's fine. > > ~ Ari Chivukula (Their/There/They're) > > > On Wed, Apr 19, 2023 at 11:32 AM Rick Byers <rby...@chromium.org> wrote: > >> This makes a lot of sense to me. Normally we prefer to approve shipping >> only after spec PRs have landed, it looks like the PR is blocked on some >> work from you including landing the WPTs, right? I'd suggest you get this >> all landed under a status=experimental RuntimeEnabledFeature and see if we >> can get the PR reviewed and landed in short order before trying to flip to >> status=stable, WDYT? >> >> Rick >> >> On Wed, Apr 5, 2023 at 2:46 PM 'Ari Chivukula' via blink-dev < >> blink-dev@chromium.org> wrote: >> >>> https://github.com/w3ctag/design-reviews/issues/833 >>> >>> On Wednesday, April 5, 2023 at 11:27:22 AM UTC-4 Alex Russell wrote: >>> >>>> Please file an issue with the TAG as an FYI and let us know when they >>>> respond. Their job is to help us drive coherence across the platform and >>>> spot architectural patterns. There might be other occurances of similar >>>> oversights that they can help us spot and fix. >>>> >>>> Best, >>>> >>>> Alex >>>> >>>> On Tuesday, March 28, 2023 at 11:15:31 AM UTC-7 Ari Chivukula wrote: >>>> >>>>> Contact emails >>>>> >>>>> ari...@chromium.org, mike...@chromium.org, yoav...@chromium.org >>>>> >>>>> Specification >>>>> >>>>> https://github.com/w3c/navigation-timing/pull/188 >>>>> >>>>> Summary >>>>> >>>>> Websites can indicate that a particular Client Hint >>>>> <https://wicg.github.io/client-hints-infrastructure/> is critical to >>>>> the page by including it in a `Critical-CH` HTTP response header. Doing so >>>>> will trigger a connection restart if the hint listed in the `Critical-CH` >>>>> HTTP response header could be (but wasn’t) included in the HTTP request >>>>> initially sent. This intent proposes adding `readonly attribute >>>>> DOMHighResTimeStamp criticalCHRestart;` to the >>>>> `PerformanceNavigationTiming` interface. >>>>> >>>>> >>>>> Blink component >>>>> >>>>> Blink>PerformanceAPIs>NavigationTiming >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component%3ABlink%3EPerformanceAPIs%3ENavigationTiming> >>>>> >>>>> Motivation >>>>> >>>>> It’s possible for websites to observe a change in the Navigation >>>>> Timing <https://github.com/w3c/navigation-timing> related to >>>>> `responseStart` and `requestStart`, but there is no explicit timestamp >>>>> that >>>>> indicates when this occurred. Without that it’s harder for sites to detect >>>>> the impact that the `Critical-CH` HTTP response header has on >>>>> connections. Developers (including Akamai) are interested in using this to >>>>> better understand the impact of User Agent Client Hints / User Agent >>>>> Reduction. >>>>> >>>>> `criticalCHRestart` can only be set for top-level frames, as >>>>> subresources and iframes ignore `Critical-CH` HTTP response headers. >>>>> >>>>> TAG review >>>>> >>>>> N/A, this is a small, incremental addition to an existing feature for >>>>> convenience and the loaded website has other (less convenient) ways to >>>>> detect a Critical-CH restart. >>>>> >>>>> >>>>> Compatibility & Interoperability >>>>> >>>>> We would be the first to implement if approved. >>>>> >>>>> >>>>> Gecko: https://github.com/mozilla/standards-positions/issues/767 >>>>> >>>>> >>>>> WebKit: https://github.com/WebKit/standards-positions/issues/156 >>>>> >>>>> >>>>> Web Developers: Requested by Akamai >>>>> <https://github.com/w3c/navigation-timing/issues/177> >>>>> >>>>> Is this feature fully tested by web-platform-tests? >>>>> >>>>> No, but it will be. >>>>> >>>>> Tracking bug >>>>> >>>>> https://crbug.com/1425910 >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> >>>>> https://chromestatus.com/feature/5140317616996352 >>>>> >>>>> -- >>> 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+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0dacf540-c8be-4096-9ad1-bc7a99af630cn%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0dacf540-c8be-4096-9ad1-bc7a99af630cn%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- 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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY86kXsibK3D0dCyVtwVWG5U9TUBANVo_-6Lca5XjQCHgQ%40mail.gmail.com.
