ServiceWorker static routing API

[yoshisatoyanagisawa]

こんにちは TAG-さん!

I'm requesting a TAG review of ServiceWorker static routing API.

This API allows developers to configure the routing, and allows them to offload simple things ServiceWorkers do. If the condition matches, the navigation happens without starting ServiceWorkers or executing JavaScript, which allows web pages to avoid performance penalties due to ServiceWorker interceptions.

• Explainer¹ (minimally containing user needs and example code): url
• User research: it is a well-studied phenomenon that faster sites are better for users, but we have not conducted any user studies specifically on this feature.
• Security and Privacy self-review²: url
• GitHub repo (if you prefer feedback filed there): url (proposed to move to WICG)
• Primary contacts (and their relationship to the specification):
  • Yoshisato Yanagisawa (@yoshisatoyanagisawa), Google
  • Shunya Shishido (@sisidovski), Google
• Organization/project driving the design: Google Chrome
• External status/issue trackers for this feature (publicly visible, e.g. Chrome Status):
  • ChromeStatus
  • Mozilla standards position
  • WebKit standards position

Further details:

• [x] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): W3C Service Workers Working Group
• The group where standardization of this work is intended to be done ("unknown" if not known): W3C Service Workers Working Group
• Existing major pieces of multi-stakeholder review or discussion of this design: https://github.com/w3c/ServiceWorker/issues/1373
• Major unresolved issues with or opposition to this design: Maybe no as far as I took a glance at https://github.com/w3c/ServiceWorker/issues/1373
• This work is being funded by: Google

You should also know that...

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

[maxpassion]

Hi @yoshisatoyanagisawa, We had a discussion in our breakout C meeting this week. One concern is that this proposal uses URLPattern but URLPattern has not been standardized. Is there any update on this?

[yoshisatoyanagisawa]

Thank you for reviewing our proposal! @domenic @wanderview Do you know the current URLPattern status?

[domenic]

URLPattern is fully specified. It's true that it hasn't moved to a standards organization, but that's due to other browsers choosing not to implement, which isn't something we can speak to; you'd have to ask representatives of other browsers about their plans in that area.

[torgo]

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?

[domenic]

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

I don't think it's a good idea to invent a second URL pattern syntax for routing on the web platform, and you need some sort of syntax for specifying URL patterns if you're to statically give a pattern for which URLs are routed...

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.

Thanks for highlighting this! We will work to ensure that feature uses the platform's common URL pattern syntax which is designed in the URL pattern spec. I filed https://github.com/WICG/compression-dictionary-transport/issues/48, but it looks like this is already under discussion in https://github.com/WICG/compression-dictionary-transport/issues/42.

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

Again, I think there's nothing blocking this besides the other implementations' interest. Chrome has done everything we can by laying out a full specification, web platform tests suite, and so on. The "way forward" is for another implementation to support standardization, and that's not something the Chrome team has control over. I'd really encourage the TAG to bring these concerns up with the other engines directly, instead of the current approach (which I see across multiple reviews) of asking Chrome team members for information on the future plans of other companies.

[kenchris]

URLPattern is quite popular judging from our polyfill https://www.npmjs.com/package/urlpattern-polyfill which has 3.5M weekly downloads. It is also implemented in Deno https://deno.land/api@v1.36.4?s=URLPattern

[torgo]

I'd really encourage the TAG to bring these concerns up with the other engines directly, instead of the current approach (which I see across multiple reviews) of asking Chrome team members for information on the future plans of other companies.

@domenic I think you know it's not the TAG's job to sell Google's vision of the web to other browser makers. Having said that, we are trying to drive cross-platform consensus around topics such as Powerful APIs and Web Privacy - I suggest you attend those sessions at this week's TPAC plenary to learn more.

[torgo]

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, we'd encourage you to pursue that path.

[chrishtr]

Considering there seems to be a way forward for standardization, we'd encourage you to pursue that path.

FYI the URL Pattern spec is now at the WHATWG and Webkit is positive on this proposal.