Editorial: fold cannot-be-base-URL into path

[annevk]

Fetch PR: whatwg/fetch#1337.

HTML PR: whatwg/html#7240.

URLPattern PR: whatwg/urlpattern#143.

Fixes #634.

---

Preview | Diff

[wanderview]

I think URLPattern would also need to be updated after this change.

[annevk]

Thanks Ben! This took a bit more effort than expected, but I think it does look rather nice and having the URL path serializer will also allow for some nice cleanup elsewhere, in particular in HTML. This will need to be validated in jsdom's whatwg-url (ideally by someone that's not me) and I'd like @karwa @TimothyGu @alwinb @domenic to be okay with it.

I'm not a big fan of "string path state". I considered renaming path in the other path-related states to hierarchical path, but I think it would be confusing if the lone path state ended up being the exceptional case.

[TimothyGu]

I really like this cleanup! It would also match how Go's net/url package stores paths better, and convergence is always nice.

[alwinb]

I like this a lot, much better!

[annevk]

I addressed the review comments. This made me think "hierarchical path" was no longer pulling its weight. I hope that's still agreeable. We could always add it back at some future point once there is a more compelling need.

I'll see how easy it is to update whatwg-url these days. Edit: it was straightforward and the tests are passing.

[alwinb]

I just spotted that the id attribute on the opaque path state is unchanged as "cannot-be-a-base-url-path-state". I don't know if that is intentional.

[annevk]

Yeah that is intentional. I prefer keeping old IDs around so old links keep working. I also like that it shows the document has some history. We can of course add a new ID as well, but it's not always clear to me that is worth the additional bytes and nodes.

[karwa]

(Apologies for not responding sooner; I've been away. I didn't expect all this activity! 😅)

Thank you so much @annevk! This is really fantastic; it seems to have involved coordinating a lot of updates to other standards, which can't have been easy, but I think it makes this standard significantly better.

The motivation for #634 was so I could explain to users of my URL library which operations may fail and why, without inventing my own terminology that they can't search for on the web. This helps make a lot of the limitations around URLs with opaque paths much less... well, opaque:

• Why can't I split this URL's path in to components? Because it's an opaque string, not a list.
• Why can't I set a hostname on this URL? Because it would be separated from the path with a "/", turning the path in to a list.
• Why can't I resolve a relative reference against this URL? Because its path is opaque; we can't split it up to add/remove components.

Which is a lot better than saying "because the parser decided to set some flag which forbids it". So I definitely appreciate it, and I'm sure my users will also very much appreciate it.