Use "inherit left, wildcard right" behavior in base URL application and constructor string parsing.

[jeremyroman]

The following changes apply to patterns which are constructed using a base URL, the constructor string syntax, or both -- but not any pattern which explicitly specifies components separately without a base URL.

• Components are not inherited from a base URL if an "earlier" component is explicitly specified.
• In the string format, unspecified "later" components are implicitly wildcarded, rather than required to be empty (with the exception of the port, which is always taken to be specified when the hostname is).
• Username and password are never implicitly specified or inherited.

For example:

1. "https://example.com/*" also matches with any username, password, search, and hash. Previously this would be written "https://*:*@example.com/*\\?*#*".
2. new URLPattern({ pathname: "/login" }, "https://example.com/?q=hello") accepts any query string and hash, not only "?q=hello" and "".
3. "https://*:*" or {protocol: "https"} means "any HTTPS URL, on any port", and "https://*" means "any HTTPS URL on the default port (443)". These have the same meaning whether or not a base URL is provided, since specifying the protocol prohibits inheritance of other components.

This makes patterns more expansive than before, in cases where wildcards are likely to be desirable.

The logic of inheriting components from a base URL dictionary is also similarly changed in a way that may make it not match where it did before, but more consistently with the above and with how relative URL strings are resolved. For example, new URLPattern("https://example.com/foo?q=1#hello").test({pathname: "/foo", hash: "hello", baseURL: "https://example.com/bar?q=1"}) previously returned true but will now be false, since the search component is not inherited when the pathname is specified. This is analogous to how new URL("/foo#hello", "https://example.com/bar?q=1") works. The reverse is also possible; in both cases this is quite niche.

Fixes #179.

---

• [x] At least two implementers are interested (and none opposed):
  • Google Chrome
  • Safari (per https://github.com/whatwg/urlpattern/issues/179#issuecomment-1735850741)
• [x] Tests are written and can be reviewed and commented upon at:
  • https://chromium-review.googlesource.com/c/chromium/src/+/4975595
• [x] Implementation bugs are filed:
  • Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1468446
  • Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1731418 (vendor does not yet implement the spec)
  • WebKit: [no known URLPattern bug] (vendor does not yet implement the spec)
  • Deno: https://github.com/denoland/deno/issues/21073
  • kenchris/urlpattern-polyfill: https://github.com/kenchris/urlpattern-polyfill/issues/122
• [x] MDN issue is filed: https://github.com/mdn/content/issues/30024
• [x] The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[jeremyroman]

@sisidovski @domenic FYI

[jeremyroman]

Updated commit message in the opening comment (hopefully it's reasonably clear).

I assume Gecko and WebKit implementation bugs are not desired since they don't yet (to my knowledge) implement URLPattern; is that right? I can file Deno and urlpattern-polyfill ones shortly before merging if appropriate. Ditto for MDN.

For implementer interest, it sounded like Anne was on board with this direction; what level of assent is required to add WebKit to the implementer interest list?

[domenic]

Updated commit message in the opening comment (hopefully it's reasonably clear).

LGTM! You might want to add something about the compatibility implications, and how we've measured them to be low.

I assume Gecko and WebKit implementation bugs are not desired since they don't yet (to my knowledge) implement URLPattern; is that right?

Right, we can treat them as being under the umbrella "implement URLPattern" bugs.

For implementer interest, it sounded like Anne was on board with this direction; what level of assent is required to add WebKit to the implementer interest list?

What I would do is check the box for WebKit, linking to https://github.com/whatwg/urlpattern/issues/179#issuecomment-1735850741 , but also tag @annevk to confirm, and give a few days before merging in case he has objections or wants to take a closer look.

[jeremyroman]

What I would do is check the box for WebKit, linking to #179 (comment) , but also tag @annevk to confirm, and give a few days before merging in case he has objections or wants to take a closer look.

Alright, will do unless @annevk objects.

[annevk]

I didn't do an in-depth review, but happy to agree on behalf of WebKit with the behavior we're aiming for here.

[sisidovski]

Apologize for the delay, LGTM with a few questions.

[jeremyroman]

Chromium CL has also landed, and should ship in M121. 🤞