FWIW, the actual feature the spec is tied to shipped 2 years ago: https://chromestatus.com/feature/5124977788977152
The RFC was ratified some last year if I remember right. The fetch and html spec PR's have mostly been waiting on a second implementor and for final sign-off from the owners before merging. There have been a bunch of spec language/flow changes since the feature launched but mostly just to get the PR to properly plug the RFC into the spec-defined path - the Chrome implementation hasn't substantially changed. I'm not 100% sure that the new platform status entry is needed. AFAIK, it's mostly fixes to align with the actual spec writeup and there were a couple of bugs that were closed but nothing that changed from a web developer's perspective (except maybe the compression-dictionary dest). There were a lot of WPT tests added as part of the effort to make sure we have consistent cross-browser behavior, particularly around CORS handling. On Wed, Sep 30, 2026 at 11:12 AM Yoav Weiss (@Shopify) < [email protected]> wrote: > Looking at WPTs, it seems like Firefox is passing most of them: > https://wpt.fyi/results/fetch/compression-dictionary?label=experimental&label=master&aligned > > Do you know if they shipped with these updates? Are there tests for these > updates? > > On Wednesday, September 30, 2026 at 4:48:58 PM UTC+2 Daniel Bratell wrote: > >> Looking at the shipping entry in chromestatus, it seems to lack the >> necessary reviews for privacy, security and so on. Can you please request >> those parts? >> >> (Yoav mentioned this last week but maybe his mail got lost) >> >> /Daniel >> On 2026-09-28 16:39, Frédéric Wang Nélar wrote: >> >> >> Le 21/09/2026 à 20:17, 'Dan Clark' via blink-dev a écrit : >> >> *> Specification* >> *> https://github.com/whatwg/html/pull/11620 >> <https://github.com/whatwg/html/pull/11620>* >> >> Is anything blocking this spec PR from landing? >> >> Patrick can say more but I think this just pending review from the WHATWG >> editors and addressing review comments, no fundamental blockers. >> >> That said, this PR is much bigger that the small changes proposed here. >> Actually none of the compression dictionary PRs ( >> https://github.com/whatwg/html/pull/11620 >> https://github.com/w3c/webappsec-clear-site-data/pull/94 >> https://github.com/whatwg/fetch/pull/1854) are merged yet but API owners >> already approved shipping this feature in >> https://groups.google.com/a/chromium.org/g/blink-dev/c/MuaRf28nExk. The >> change I'm proposing here only aligns with the spec PR / tests / webkit so >> in some way, doing soe would help a bit to get the spec PR merged. >> >> > *Interoperability and Compatibility* >> *No information provided* >> >> Since this would change a shipped API, can you comment on the >> compatibility risk? Is there a possibility that sites already using the >> feature could be affected? >> >> Again, Patrick is probably in a better position to comment, but AFAIK we >> haven't done any stats on current usage, because the expectation that this >> change is minor and wouldn't have compat impact: >> >> - For the fetch parameters, I understand they were too restrictive in the >> initially shipped implementation, and were also ignoring attributes that >> allow to change the default behavior. So removing this restriction >> shouldn't "break" websites (in the sense that some fetches could start >> being blocked). It also aligns with what other kinds of links are doing, so >> it's something more expected for developers and following existing security >> models. >> >> - Regarding the "compression-dictionary" string, typical way of >> triggering a dictionary load is via the link element / header and the >> destination string is only set when the fetch request is created, without >> implication on how the compression dictionary is used later. It's possible >> for developers to observe this destination string (WPT tests I mentioned >> above do that with some complex logic involving a worker that observes >> fetch events) but it's not clear to me what would be the use case for that. >> >> >> -- >> 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 [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5cb080a5-6d3d-4205-a1ed-23755ad23ec9%40igalia.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5cb080a5-6d3d-4205-a1ed-23755ad23ec9%40igalia.com?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 [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPq58w4%2BAL1inngaMQfC1%3DougtdjE%2BeO%3D39kvHYmE5z%2BJNB2hQ%40mail.gmail.com.
