Proposal: Add WHATWG URL API

[jasnell]

Proposal to add the WHATWG URL and URLSearchParam APIs as intrinsic objects.

https://github.com/jasnell/proposal-url
https://url.spec.whatwg.org/#api

/cc @domenic

[domenic]

/cc @annevk

[jasnell]

Just to be clear... the proposal here is for ECMAScript to use the WHATWG spec as the normative reference and definition of this API as opposed to TC-39 taking the spec over in any way.

@jkrems... sorry, accidentally had it marked private. public now.

[annevk]

Proposal is a 404? Curious how this deals with subtle IDL differences. There's also a couple proposals to further extend the URLSearchParams object, one which would tie it to forms.

[jasnell]

@annevk ... sorry about the 404, repo is public now.

[jasnell]

@annevk ... with regards to the IDL differences, that's something I've yet to fully work out. The hope, as much as is feasible, would be for TC-39 to simply defer to the WHATWG spec as the normative definition of the URL and URLSearchParams objects while allowing those to continue evolving as necessary. I've yet to determine just how problematic those IDL differences may be (if at all).

[domenic]

I don't think the IDL differences will be problematic, really. Skimming, the ones I can see are:

• enumerable (Web IDL) vs. non-enumerable (conventional for ES)
• urlSearchParams.get() returning null (Web IDL) vs. undefined (conventional for ES) on no match
• statics being functions (Web IDL) vs. methods (conventional for ES)not applicable after whatwg/url@2bd0f59

In all cases just deferring to the current Web IDL behavior seems fine (although that undefined vs. null still makes me a little sad).

[leobalter]

There's nothing that should prevent this proposal to be listed as stage 0. Should we rebase and merge this?

[ljharb]

@leobalter I think that in this case (adding a normative reference to another spec) it might be worth getting the pulse of the committee before adding it to stage 0 - but if anyone feels strongly, it's fine to merge this as stage 0 now, pending a rebase.

[leobalter]

I would enforce that for the process to Stage 1 as I personally see Stage 0 as a list of ideas if not anything else.

In the meanwhile, we can resolve the merge conflicts but I just want to confirm with @jasnell if he still wants to add it.

[jasnell]

Yes, absolutely

[ljharb]

This seems to have broken some of the whitespace changes added; this shouldn't have been merged with this large a diff.

[leobalter]

this is weird, I thought I got these fixed through GH's merging tool.

This is how I see the diff: https://www.dropbox.com/s/or9soz53vn2yb1t/Screenshot%202017-06-13%2015.55.27.png?dl=0

[leobalter]

also the raw file seems ok: https://raw.githubusercontent.com/tc39/proposals/master/stage-0-proposals.md

It looks like you're looking only at the last commit, resolving the merge conflicts, but not the final set of changes.

I wanted to squash but this repo requires the merge commit with all the commits from the PR.

[ljharb]

ah, that might be the case. if you'd rebased instead of merged master this wouldn't have occurred (in the PR, prior to merging)