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

@magcius
You're directly contradicting the spec. The spec claims to "[define] URLs, domains, IP addresses, the application/x-www-form-urlencoded format, and their API." It also claims its goal is to "[align] RFC 3986 and RFC 3987 with contemporary implementations and obsolete them in the process."

If the WHATWG is to obsolete these RFCs and to provide a replacement definition of URLs, it must consider more than just web browsers (especially just Chrome, I'm not convinced that the Chrome bias is fake). That the WHATWG is specifically about web applications is just one reason the specification should have a much, much narrower scope than it claims.

Regarding Safari, iOS and Internet Explorer moving to implement what this standard says, this could just as well be turned the other way by not allowing multiple slashes (which is the solution favored by the RFCs, simplicity, and correctness, remember) and expecting Chrome and Firefox to adjust. But of course we expect Safari, iOS and Internet Explorer to adjust, as well as all the other programs that parse URLs that don't get mentioned simply because only browsers seem to be cared about. Why is that?

I seriously don't think the WHATWG should be defining concepts such as URLs, domains or IP addresses. This specification is only useful for web browsers (even then I'm not too sure about that...), so its scope should be restricted to those.

@SEAPUNK, @domenic
Plan which is not going to happen, and therefore not reasonable, because any reason we could have to be permissive right now is only going to become even stronger once a spec says it's okay to be permissive. If making the spec increasingly stricter makes sense, making it stricter right now would make even more sense. If anyone is going to update his broken URLs (doubtful), it's only going to be less likely to happen once a spec says they are not broken and all browsers support them. So the only thing I see happening is the spec becoming more permissive, not stricter. And this is obviously a problem, I hope nobody wants URL parsing to become as complicated and full of heuristics (even if these heuristics are well-defined in a spec, they're still heuristics) as parsing of HTML5 has become.

---
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-218650824