Re: [whatwg/url] It's not immediately clear that "URL syntax" and "URL parser" conflict (#118)

@nox This issue thread describes exactly why this standard doesn't describe reality.

It doesn't even come close to describing Safari, or any utility that handles URLs outside of browsers. Not a single programming language changed its stdlib's URL parser according to the standard.

Today, you can not use the URL format given here to give a URL to the Google Chrome browser on Android, instead, to programmatically invoke it, it will only accept RFC-conform URLs.

Out of over a thousand tools, and several hundred URL parsing libraries, and hundreds of browsers, only 3 (!) match what this standard describes today.

The exact same 3 that defined this standard. And, as mentioned above, not even they fully accept it.

Defining "URL" for the entire Internet in a new way requires a definition that also applies to URL parsing libraries in programming languages, that applies to cURL, wget, the Android Intent system, CLI invocations of browsers, and more.

So either rename this, to make it clear you don't even care at all about the ecosystem outside of browsers — as suggested, Web Resource Locator would be one alternative to Uniform Resource Locator — but redefining the Uniform Resource Locator for the entirety of modern information technology requires discussion with more stakeholders (see the libcurl author higher up in this thread complaining), and it requires it to actually stay uniform. The very definition of a uniform resource locator is that there is only a single possible serialization, and only one way to parse it, and that this is standardized across all software.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/118#issuecomment-337847426