On Thu, Oct 13, 2016 at 10:54 AM Christoph M. Becker <cmbecke...@gmx.de> wrote:
> On 07.10.2016 at 16:45, David Walker wrote: > > > On Fri, Oct 7, 2016 at 4:37 AM Nikita Popov <nikita....@gmail.com> > wrote: > > > >> Are you aware of the WHATWG URL standard [1]? Quoting the first goal > >> statement: > >> > >>> Align RFC 3986 and RFC 3987 with contemporary implementations and > >> obsolete them in the process. (E.g., spaces, other "illegal" code > points, > >> query encoding, equality, canonicalization, are all concepts not > entirely > >> shared, or defined.) URL parsing needs to become as solid as HTML > parsing. > > > > I was not. I assume that WHATWG ought to supersede the IETF standards on > > the subject. I can obviously make an implementation follow the standards > > and algorithms set out in this doc. > > That might be hard, because WHATWG has "living standards", i.e. they can > change over time. If we state that our new functionality conforms to > WHATWG's URL standard we have to always apply the latest changes even > into revisions, potentially causing BC breaks. > We could say that we support WHATWG@f88f96 and support the previous 2, or 3, keeping in line with some BC ability. But yes, it would be a nuisance and overly complex to keep updating the parser for frivolous changes (like that commit) which re-makes fragments an optional part of a URL. I'd be more apt to stick to a single 3987/3988 compatible parser, which ought to be future compatible with WHATWG. It would just lack any of the standardization terms, object models, and rigid-parser definitions. That's to say that WHATWG maintains the requirements of the 2RFC and just expands on them. This also plays with what Larry is saying by keeping the parsing, and object-side of things separate. WHATWG does have a very nice layout of the URL/SearchParams, and how they can play with eachother. I'd think that end of the spec should be left for userland classes, in the event a new PSR wants to propose implementing the WHATWG format of URL/SearchParams/Hosts, etc. -- Dave
