I've said it before. The WHATWG won't fix this because they are happy with a spec that works for them and they don't care about URLs for the rest of the world.

The IETF has given up the topic, partly I think because WHATWG already has stated that they run their own race and making a unified spec that works would be next to impossible.

@bagder My perception of WHATWG (as a traumatized but recovering browser engineer) is that they aren't / weren't issuing specifications, they are / were issuing documentation (for existing behaviors).

The distinction is important, because, when implementation and specifications disagree, the implementation is wrong; however, when implementation and documentation disagree, the documentation is wrong.

@jbqueru I've been told in discussions with WHATWG people that their specs (they call them specs) are both: documents how browsers work and they say how browsers should work. When I've pointed out discrepancies in the past (browsers that didn't follow their spec), the answer have usually been that it will be fixed in a future browser release and that the spec is right.

@bagder That's been my experience as well.

I personally disagree with the approach, because the so-called "spec" ends up ossifying the behavior of a prototype, instead of learning from it and creating a cleaner spec. WHATWG doesn't learn from mistakes or fix them, it propagates and perpetuates mistakes.

@jbqueru @bagder well then. that's not engineering. that's hoarding behavior.

@suzannealdrich @jbqueru and its impossible to be perfectly compliant because then suddenly the "spec" changes and you're not anymore. Not a way to build things like URLs that are supposed to in theory be possible to outlive us all.

@bagder @suzannealdrich @jbqueru

I know I'm coming at URL parsing from a clean brain, but can't we specify the base things in an actually parseable way? Surely it's not *that* hard to parse a URL?

@dascandy @suzannealdrich @jbqueru we could theoretically do that, sure.

@bagder @suzannealdrich @jbqueru

Taking a stab in the dark with some EBNF:

url ::= protocol '://' [ name [ ':' name ] '@' ] [ server ] [ '/' [ path ] [ '?' arg { '&' arg } ] ]
protocol ::= name
server ::= name { '.' name }
path ::= name { '/' name }
arg ::= name [ '=' name ]

name = ([^:/@?&=.%]|%[0-9a-f][0-9a-f])+

I understand that whatwg makes that :// not a required part ... but this kinda matches what my naive brain thinks of as a URL and how to read it.

@dascandy @suzannealdrich @jbqueru add port numbers, IP addresses (v4, v6, zone id?), add options? How about IDN?

I see you used two slashes, but URIs actually don't have that. Many have no slashes at all.

But sure, everything *could* be written down in a spec. Getting the world to agree with that spec though: not so easy.

@bagder @suzannealdrich @jbqueru

If Curl and Firefox start by advocating "this is the spec for URIs, and other things might work or might not" that would already be a good start for the free internet.

Then we only have Chromium to convince, and the rest follows implicitly.

@dascandy @suzannealdrich @jbqueru I'm sorry but already while I worked at Mozilla and Firefox my colleagues were in team WHATWG and I'm pretty sure they still are.

And doing a standard for URLs without having the super powers involved and interested is obviously not going to make a successful spec

@bagder @suzannealdrich @jbqueru also I note from your post that you find the WHATWG URL spec hard to read but I have to say that in general I find all WHATWG specifications nigh-unreadable

English but precisely defined pseudocode has to be one of the worst possible ways to write a specification