Re: A URL API

On 9/17/10, Adam Barth <w3c@adambarth.com> wrote:
> 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.
>

You don't know if it is defined or not? Makes no sense at all.

>> 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;
>>
>> ?
>
SO you're saying that

x.searchParameters.title is an object with property names that
correspond to URL parameters -- again -- makes no sense. It looks like
you didn't understand question so I'll rephrase and elaborate:

If, for each parameter, the dictionary gets a key entry with the value
corresponding to the parameter name, then what is the value associated
with that key. Referring again to the xample, what would be the value
of x.searchParameters.title -- an Array?

And what of the prototype of that Dictionary? Another object with
nonstandard catchall behavior? No thanks on that. What is the value of
x.searchParameters.valueOf? undefined? A function? Null?

Storage also has live-Dictionary features but does not use Dictionary.
Seems like a common interface.

<http://dev.w3.org/html5/webstorage/#storage-0>

get/set/remove/clear all make sense there, but so do batch adds, e.g.
setItems(obj).

Working with parameter values can be a tricky if, say, the the program
wants to remove one value for title and keep another. If URI has a
getParameterMap then it should either be live or it should have a
setParameterMap method. The one way API makes no sense.
-- 
Garrett

Received on Friday, 17 September 2010 21:40:03 UTC