Re: [whatwg/url] Support relative URLs (#531)

@alwinb So far, the most convincing use-case that I've seen is that somebody on the NodeJS issue wanted to construct relative references. OK, that's a thing.

But does that require the full complexity of the URL parser and all the work that you've done to establish a formal grammar and theory of URLs (which is certainly very interesting, don't get me wrong)? I'm not sure that it does. I think we could solve that with a simple data structure containing the broken-down URL components -- e.g. a list of path segments you could directly append to/remove from, and some simple methods to define how we serialise that structure as a relative reference.

I think it's important to remember that the URL parser in this standard does not represent the cleanest definition of URLs. The thing that gives it value is that it incorporates all of the weird compatibility hacks actors on the web platform need to consider when interpreting URLs. With every change, we have to consider what browser X, Y, and Z does, and whether we can call it a reasonable interpretation of how people expect URLs on the web to work.

For new APIs which don't have any of those compatibility concerns, I think we should be striving for the simplest design that solves the problems we actually have. Propagating those hacks beyond what is needed for compatibility should **not be goal** IMO. And those APIs should ideally be used in production for a while before proposing standardisation.

But instead, you're just coming and saying you've solved all the problems on your own, in a purely academic exercise that has not been used in production and is apparently not even driven by specific problems encountered in a real application (or was it?). I'm not sure what you expect other than scepticism. I would really love to offer more support, but I just can't consider this as a realistic proposition.

I would suggest following an approach similar to URLPattern - another new API that is closely related to this standard. Produce a focussed document and API for a specific problem, cut _everything_ that isn't needed, produce an implementation, let users work through the issues, and build up a test suite as edge-cases are discovered, etc.

Anyway, that's _my_ opinion. I'm not an editor of this standard so it's "non-normative" 😅, but I'm offering it because you have clearly studied the standard, and I'd rather help you to not waste your time developing overly-broad, overly-abstract specifications.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/531#issuecomment-1032991440

You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/url/issues/531/1032991440@github.com>