URLPattern object literal syntax results seem unintuitive

[domenic]

Continuing discussion from an internal thread. This is halfway between a URLPattern issue, and a platform-integration-with-URLPattern issue. E.g., I think we'd see similar things come up if we attempted to integrate URLPattern into other headers, or use it to replace the ad-hoc patterns we see in existing headers like CSP. So I'd love @wanderview's take.

In https://github.com/domenic/blog.domenic.me/blob/1a367f722a6571879aa5a92faaf5a32f657ffd60/src/js/preload.mjs#L22 I did

where: { href_matches: { protocol: "https" } }

thinking this would mean, any link which matches the https protocol. I.e., it would be equivalent to new URLPattern({ protocol: "https" }).

Instead, it's equivalent to new URLPattern({ protocol: "https", baseURL: document.baseURI }). Since the base URL already has https: as its protocol, this basically means I've constructed a URLPattern that only matches the current page.

Trying to fix this by expanding the pattern to { protocol: "https", pathname: "*" } kind of works... but then it doesn't match anything with a non-empty query string, or fragment. You end up needing

{
  protocol: "https",
  pathname: "*",
  search: "*",
  hash: "*"
}

I don't know what a good solution is here. Here are some ideas, none of which are very satisfactory:

1. Have no base URL for the object literal form. (So that the left-out components default to "*" instead of drawing from the base URL.)
2. Have no base URL for both the object literal form, and the string form. (This makes the string form fairly unwieldy, as now you can't use relative URL-like pattern strings.)
3. Some sort of mechanism for wildcarding "everything from here onward", similar to what's discussed in the end of All our examples using /*\\?* URL pattern syntax break for fragment links #259. Then you could do { protocol: "https", pathname: "**" } maybe?
4. Some sort of way of implicitly wildcarding everything from the first wildcard onward? I.e. make { protocol: "https", pathname: "*" } automatically get search: "*" and hash: "*".
5. Better DevTools: show the "resolved form" of the pattern, and/or show which URLs on the current page a given pattern matches.

I am pretty convinced that in the current form, the object literal URLPatterns are somewhat useless for most people, because they'll almost always need to fill in a bunch of "*" entries. I think this is an echo of the problem in #259 and the problem we've noted before where /*\\?*#* is a pretty confusing way of saying "everything on this origin". It's just more painful for object literals since they're more verbose.

[wanderview]

It feels like your integration needs a way to signal not to use the base URL.

[jeremyroman]

One approach would be adding null to the list of values accepted for "relative_to".

"where": {"href_matches": {"protocol": "https"}, "relative_to": null}

It certainly makes this possible, but it's regrettably that either way we need to force you to choose rather than the syntax making the right choice natural. (And having different defaults for object and string syntax seems...inconsistent. Even though I suspect it would yield the "right answer" more often.)

[jeremyroman]

Due to whatwg/urlpattern#198, where: { href_matches: { protocol: "https" } } will now do what you expect (any HTTPS URL).