Intent to Ship: URLPattern

[Ben Kelly]

Contact emails

wande...@chromium.org

Explainer

https://github.com/WICG/urlpattern/blob/master/explainer.md

Specification

https://wicg.github.io/urlpattern/

Summary

URLPattern is a new web API that provides native support for matching URLs given a pattern string. It is designed to be usable both in javascript directly and by passing patterns to other web platform APIs; e.g. as a service worker scope.

Blink component

Blink

TAG review

https://github.com/w3ctag/design-reviews/issues/417

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

This API has minimal interop and compat risk. It can easily be feature detected and a polyfill is available at: https://www.npmjs.com/package/urlpattern-polyfill

Gecko: No signal (https://github.com/mozilla/standards-positions/issues/566)

WebKit: No signal (https://lists.webkit.org/pipermail/webkit-dev/2021-August/031942.html)

Web developers: Positive (https://github.com/WICG/urlpattern/blob/main/dev-trials-feedack.md)

Ergonomics

The URLPattern API will often be used with the URL API. To make this more natural we have tried to match URL behavior and API shape wherever possible. URLPattern is also similar in nature to RegExp and we have attempted to match its API shape as well; e.g. providing `test()` and `exec()` methods. In regard to the ergonomics of the pattern syntax itself, we have adopted the syntax from the popular javascript library path-to-regexp. Our hope is that using a popular syntax will result in the web API being more natural for developers to use.

Activation

The URLPattern API is easily feature detected and a polyfill is availabe at: https://www.npmjs.com/package/urlpattern-polyfill

Security

The main security risks involve the addition of a new parser in the platform. Since parsers are common attack vectors it does represent a risk. We mitigate this risk by requiring that URLPattern strings must be parsed in the sandboxed renderer. In addition, we are actively fuzzing the parser.

Debuggability

Currently URLPattern does not have any special integration with devtools. The summary view of the URLPattern object is already useful for inspecting what patterns it will use to match. Exceptions are used to report errors in constructing a URLPattern. In the future it may be useful to provide some kind of syntax highlighting or checking of URLPattern syntax. This seems challenging, though, as the values are passed as plain javascript strings and are not a javascript type like regular expressions. This could be an area for future exploration, though.

Is this feature fully tested by web-platform-tests?

Yes

DevTrial instructions

https://github.com/WICG/urlpattern/blob/main/howto.md

Flag name

about://flags/#enable-experimental-web-platform-features

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1141510

Estimated milestones

DevTrial on desktop	93
DevTrial on Webview	93

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5731920199548928

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msg/blink-dev/jBMvUEkyBq8/IwYIZmhEBQAJ
Ready for Trial: https://groups.google.com/a/chromium.org/g/blink-dev/c/WitVII_BzyU/m/mI8lZY4NAgAJ

This intent message was generated by Chrome Platform Status.

[Domenic Denicola]

Non-owner LGTM!

As Ben's spec mentor, I want to mention how well the specification-writing process for this has gone. Not only did Ben produce an extremely thorough spec, with review for every commit, but we also had the good fortune of getting a second implementation as the spec came out, which found a number of small bugs that slipped through review. In combination with the good web platform tests which have high coverage, I'm confident that the resulting spec will be interoperably implementable.

Separately, I want to note how this is a great instance of responsible platform evolution. At the original TPAC where URL pattern matching for service worker scopes was proposed, there was some worry that we might create a solution that is good enough for service workers, but not useful for web developers in general. Ben took this criticism to heart and prioritized this general URLPattern API, with lots of involvement from the web developer community, to ensure that we're creating something generally useful.

-Domenic

--
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/CAK7rkMgCrO2VN09hUEvfwnMBLqRWzA1NVHk%3D-PBwPhtJ%2BVO3Ag%40mail.gmail.com.

[Ben Kelly]

Since it might come up in review, I want to share my reasoning for not going through origin trial with this API:

1. I don't have a partner who has said they will use the origin trial and provide feedback.
2. Our survey showed developers would use an origin trial, but the survey did not describe what an OT is or would require for deployment.  I think this casts some doubt on these answers.
3. Developers who want to try the API in production can already do so with the polyfill without the hassle of managing OT tokens.
4. There are no UX, permissions, or other engagement type questions related to this API that an OT could help answer.

For these reasons I felt an origin trial would not be useful for this API.

[Yoav Weiss]

LGTM1

This seems like a useful addition to the platform. Thank you for the detailed explainer, your work on incorporating TAG feedback, for paving a cowpath by adopting already-used syntax and for getting developer feedback through a successful Dev Trial!

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

[Manuel Rego Casasnovas]

On 01/09/2021 15:09, Yoav Weiss wrote:
> Specification
>
> https://wicg.github.io/urlpattern/
> <https://wicg.github.io/urlpattern/>

Is there any plan to move the spec out of WICG to somewhere else?

Cheers,
Rego

[Ben Kelly]

Yes, we would like to move it to the WHATWG URL workstream in the future.  It needs a second implementor to do that, I believe.  I think typically that has meant a second browser, so not sure if the rust implementation counts.

This intent is mentioned in the spec under "status of this document".

Thanks.

Ben

 

Cheers,
  Rego

[Mike West]

LGTM2. The devtrial comment summaries were particularly helpful, and show solid improvements to the API based on developer feedback. Thank you for putting that document together.

-mike

--

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/CAK7rkMhx1m8Mog0QAD3x70VNYPBAHt-x8BNwXQnJ11iUABbUjw%40mail.gmail.com.

[Alex Russell]

LGTM3

This has been a long journey; thanks so much for all the care you've put into this, Ben.

On Thursday, September 2, 2021 at 2:10:52 PM UTC+1 Mike West wrote:

LGTM2. The devtrial comment summaries were particularly helpful, and show solid improvements to the API based on developer feedback. Thank you for putting that document together.

-mike

On Wed, Sep 1, 2021 at 4:38 PM Ben Kelly <wande...@chromium.org> wrote:

On Wed, Sep 1, 2021 at 10:28 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 01/09/2021 15:09, Yoav Weiss wrote:
>                     Specification
>
>             https://wicg.github.io/urlpattern/
>             <https://wicg.github.io/urlpattern/>

Is there any plan to move the spec out of WICG to somewhere else?

Yes, we would like to move it to the WHATWG URL workstream in the future.  It needs a second implementor to do that, I believe.  I think typically that has meant a second browser, so not sure if the rust implementation counts.

This intent is mentioned in the spec under "status of this document".

Thanks.

Ben

 

Cheers,
  Rego

--

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+unsubscribe@chromium.org.

[Ben Kelly]

Thanks all!  This is now enabled by default in M95.

On Thu, Sep 2, 2021 at 3:28 PM Alex Russell <sligh...@chromium.org> wrote:

LGTM3

This has been a long journey; thanks so much for all the care you've put into this, Ben.

On Thursday, September 2, 2021 at 2:10:52 PM UTC+1 Mike West wrote:

LGTM2. The devtrial comment summaries were particularly helpful, and show solid improvements to the API based on developer feedback. Thank you for putting that document together.

-mike

On Wed, Sep 1, 2021 at 4:38 PM Ben Kelly <wande...@chromium.org> wrote:

On Wed, Sep 1, 2021 at 10:28 AM Manuel Rego Casasnovas <re...@igalia.com> wrote:

On 01/09/2021 15:09, Yoav Weiss wrote:
>                     Specification
>
>             https://wicg.github.io/urlpattern/
>             <https://wicg.github.io/urlpattern/>

Is there any plan to move the spec out of WICG to somewhere else?

Yes, we would like to move it to the WHATWG URL workstream in the future.  It needs a second implementor to do that, I believe.  I think typically that has meant a second browser, so not sure if the rust implementation counts.

This intent is mentioned in the spec under "status of this document".

Thanks.

Ben

 

Cheers,
  Rego

--

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.