Consider adding a URLString type

[jyasskin]

What problem are you trying to solve?

While investigating w3ctag/design-principles#303, @ylafon and I wanted to search for all the WebIDL attributes that take URLs across the platform. This is difficult because URL parameters are passed as USVString (or sometimes DOMString), which of course is also used for many other purposes.

What solutions exist today?

No response

How would you solve it?

I see two alternatives:

1. Add typedef USVString URLString; in https://webidl.spec.whatwg.org/#common, and encourage fields that want URLs to take that type alias as slightly better documentation. The documentation improvement is fairly small for fields that are already named url or fooURL.
2. Add a new URLString primitive type that auto-converts between strings and URL records. This could simplify some spec prose that currently has to do the conversion itself.

I don't have a strong opinion on the naming bikeshed.

Anything else?

No response

[annevk]

I doubt most of these places can automatically convert to a URL record? I could be missing something, but I suspect more context is needed for that in most cases.

[jyasskin]

I should go look at the prose for several of these to make sure this is plausible (but I won't be able to during this week's TAG meeting), but if you're thinking about the need for a base URL, maybe https://html.spec.whatwg.org/multipage/webappapis.html#api-base-url is sufficient?

[annevk]

Maybe, but then https://url.spec.whatwg.org/#dom-url-href cannot use it. https://fetch.spec.whatwg.org/#dom-response-redirect maybe could, though that also raises the current vs relevant settings object question.

Another question is basic vs full parser, where redirect() doesn't really invoke the right one today I think.

I think you have convinced me that it would certainly be an interesting exercise to find all these endpoints to do some kind of review and assess the need for a more dedicated type.