Re: [whatwg/url] Provide a succinct grammar for valid URL strings (#479)

Let's try to avoid being overly dramatic, and assume that everybody participating in this process does so in good faith.

Nobody is going to get rich and powerful from a URL standard. Efforts like this arise from thoroughly boring technical considerations - data which is not processed consistently by applications, and a desire from engineers to ensure they are brought in to alignment.

To quote a (now 6 years old) [blog post](https://daniel.haxx.se/blog/2016/05/11/my-url-isnt-your-url/) from @bagder (emphasis added)

> A “URL” given in one place is certainly not certain to be accepted or understood as a “URL” in another place.
>
> 👉 Not even curl follows any published spec very closely these days, as we’re slowly digressing for the sake of “web compatibility”. 👈

In other words: web compatibility is more important than conformance to any particular RFC, otherwise they wouldn't deviate for its sake. That's as clear a statement as you're going to find about why the IETF RFCs have failed. It is simply impractical to take a puritan stance; pragmatism and compromise are necessary.

> two things come to mind that we do in curl that aren’t RFC3986 (apart from adding support for one to three slashes): we escape-encode incoming spaces and we percent-encode > 7bit inputs, 👉 to act more like browsers 👈. (Primarily important for redirects.)

The same is true for Python's urllib, which as mentioned departs from the IETF RFCs to strip tabs and newlines as the WHATWG standard does - essentially conforming to neither standard and creating their own URL dialect. The maintainers are aware of this (it was mentioned when they introduced that change), and it seems that they want to fully align with the WHATWG standard eventually (https://github.com/python/cpython/issues/88049).

User reports from my own library ([WebURL for Swift](https://github.com/karwa/swift-url)) suggest the same thing: that web compatibility is what people care about, more than conformance to RFC-this-or-that. Mobile apps and servers often consume poorly-formatted URLs prepared by content editors or embedded in social media posts, and there is an expectation that if it works in a browser, it should work with all other software, as well. Browser behaviour is the _de facto_ standard.

This effort is an attempt to sort that mess out - to define what "web compatibility" even means, and to produce a specification which truly can claim to describe URLs on the web. If we accept that web compatibility trumps formal compliance to any particular document (and I think that much is clear), then I simply do not understand the logic in all of this hostility and political bickering. 

What's the _worst_ that could happen from a bit of constructive engagement instead?

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

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

Message ID: <whatwg/url/issues/479/1234577410@github.com>