Max: I looked at this. The use case - is trying to solve the problem that sometimes some JS - not necessary to run all the JS using the SW - bypass the SW in some cases. So they designed this static routing API. The question I have - looking at their descritpion - uses a mechanism that is not stable yet. https://github.com/WebKit/standards-positions/issues/206 : comment that it builds on URLPattern but this hasn't been standardized..

Dan: no progress on the Mozilla standards position https://github.com/mozilla/standards-positions/issues/828

Dan: It's going to Origin Trial according to the Explainer...

Yves: I think URL pattern is a version of Regexp where most of the expeisnve things are removed....

Dan: Service Worker Scope Pattern Matching also made use of URLPattern...

Dan: I think it's concerning that something like URLPattern that is being used as a building block is still not "stable" or is sitting in WICG instead of having been brought forward...

Dan: feels like they have to have a plan for standardization of URL Pattern

max to leave comment

Dan: Some discussion... URLPattern is spec'd in a CG but not a standard due to other browsers not implementing. Doesn't sound like there's a technical issue with it.. Anne said they'd be supportive of it if the venue was resolved

Yves: position from other browser vendors is clear

<blockquote> Hi @domenic - thanks for that clarification. As with a number of other current reviews, in that case, I'd like to express concerns that we are building new capabilities on top of shaky ground – that is, existing specifications that do not have consensus and do not have multiple implementations across multiple browsers.

Further to that, we have another open review, Compression Dictionary Transport which also makes use of "URL Patterns" but does not appear to reference the URLPattern spec.

Could there be an option here to work together to specify static routing without relying on URLPattern, or to specify a fall-back?

Alternatively, is there a way forward to bring URLPattern forward for standardization that could unblock multiple implementations?

</blockquote>

Max: No response from comment... We gave them the comment that there is no standardization for URLPattern. They gave some feedback...

Dan: I don't think it's appropriate for the TAG to go chasing other browser vendors on behalf of Google... My propoosal is to close this with "satisfied with concerns" - the concerns being that this is built on top of a spec that is not being standardized anywhere... The design is fine and considering that as Ken said on sep 5, there's a polyfill available...

<blockquote> We're going to go ahead and close this with "satisfied with concerns" - we're happy with the overall design but we remain concerned about URLPattern's status on the standards track. Considering there seems to be a [way forward for standardization](https://github.com/WebKit/standards-positions/issues/61#issuecomment-1527486428), we'd encourage you to pursue that path. </blockquote>

closed with satisfied with concerns