Re: A URL API

On Fri, Sep 17, 2010 at 11:51 AM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Sep 17, 2010, at 11:36 AM, Adam Barth wrote:
>> On Fri, Sep 17, 2010 at 11:16 AM, Darin Fisher <darin@chromium.org> wrote:
>>> On Fri, Sep 17, 2010 at 11:05 AM, Adam Barth <w3c@adambarth.com> wrote:
>>>> Here's a sketch:
>>>>
>>>> https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en
>>>
>>> Nice!  Is there any implicit unescaping done when reading those members?
>>>  I'd hope for the answer to be "no" :-)
>>
>> That's a good question.  I'd expect them to just be textual segments
>> of the URL so you could reconstruct the URL by concatenating them.
>
> That would be different behavior than what Location and HTMLAnchorElement do; they unescape various componenents. Is the benefit worth the divergence?

It's probably worth being consistent even if it's slightly less
desirable for authors.

> As a side note, an out-of-document HTMLAnchorElement already provides most of the functionality of this interface. Things it can't do:
> - Resolve a relative URL against no base at all (probably not very useful since the interface can only represent an absolute URL).
> - Resolve against an arbitrary base (maybe you could do it awkwardly using <base> tag tricks).
> - Read or write the lastPathComponent or origin without further parsing (should origin really be writable? That's kind of weird...)

Making origin writeable seems to make about as much sense as making
the protocol writable.  I'm not sure it's that useful, but I also
don't see a reason to forbid it.

> - Read search parameters conveniently without parsing.

This is something I've often wanted when authoring HTML documents.

> It might be nice to provide the parts of this that make sense on HTMLAnchorElement and Location, then see if a new interface really pulls its weight.

Another piece of functionality that's missing from HTMLAnchorElement
is the automatic stringification of URL objects.  That lets you pass
URL objects into APIs that expect URLs represented as strings.  It's
unlikely that we'd want to add that part of the interface to
HTMLAnchorElement.

On Fri, Sep 17, 2010 at 11:56 AM, Anne van Kesteren <annevk@opera.com> wrote:
> We have navigator.resolveURL(url) in HTML5. I believe that was mostly for
> Web Workers. Probably because in Workers you cannot have stray <a> elements,
> or maybe because we just forgot about using <a>... (Not really been involved
> in that discussion.)

Indeed.  Workers cannot have DOM elements, which means using a non-DOM
object to parse URLs makes URL parsing functionality available to
workers.  This combines especially well with the XMLHttpRequest use
cases because XMLHttpRequest is a popular API for use in workers.

On Fri, Sep 17, 2010 at 11:57 AM, Garrett Smith <dhtmlkitchen@gmail.com> wrote:
> Where is Dictionary defined?

It might not be defined yet.

> What are the values for searchParameters
> -- can they be strings or are they only array;

In JavaScript, I'd imagine implementing them as a normal JavaScript
object with property names that correspond to the URL parameters.

> var x = new URL("http://example.net/?title=foo&title=bar);
> x.searchParameters.title;
>
> ?

The specification will define which result we get.  We'll want to look
at other parameter parsing libraries to see if the first or last
occurrence of a parameter is the more popular semantics.

> What happens if the constructor is passed a url that is not
> well-formed or unparseable per http://tools.ietf.org/html/rfc3986?

You'll likely end up with a URL object with a lot of null values for
URL components.

> What about "javascript:" pseudo-protocol?

That should work fine.

> Why not make searchParams live? And why not make it so that
> x.searchParams.add("title", "bar"); modifies the entry for that?

I think it's more elegant if searchParameters is just a plain old dictionary.

> My 2007 ES4 proposal had more, e.g. setParameterMap,  which takes an
> object and sets values on the URI.
>
> x.setParameterMap({ name : "fee", val: 12, relatedPIDs : ["3aw34", "2345f"] })

I'm not sure that's worth doing in the first version.  If there's
sufficient demand, then we can add that in a future version.

> When are components percent-encoded?

Whenever you read from the object, you observe the canonicalized
version of the URL.

> Should "protocol" be named "scheme"? I'm aware that browsers have
> location.protocol pointing to the "scheme" though some schemes e.g.
> mailto, geo are not also protocols.

I chose the names to be consistent with the other parts of the
platform that name the parts of URLs.  These names are certainly not
ideal, but consistency seems more valuable than these distinctiosn.

Adam

Received on Friday, 17 September 2010 20:02:58 UTC