Re: A URL API

On Fri, Sep 17, 2010 at 5:48 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Fri, Sep 17, 2010 at 5:43 PM, Adam Barth <w3c@adambarth.com> wrote:
>> I've removed the searchParameters attribute from the URL interface for
>> the time being.  We can consider adding it back at a later time.
>
> ;_;
>
> Just today my cubemate asked me if there was any way to get at the
> search parameters of a URL without parsing it himself.  I replied "No,
> but abarth started working on an API for it today.".
>
> That said, Garrett's right.  The values of the dict should be arrays.
> Most of the time they'll be single-element arrays, but the benefit of
> having a consistent type of value at all times is better than the
> benefit of being able to omit "[0]" from parts of your code.

I've updated the document:

https://docs.google.com/document/edit?id=1r_VTFKApVOaNIkocrg0z-t7lZgzisTuGTXkdzAk4gLU&hl=en#

Changes:

1) There are now two methods for getting at the URL parameters.  The
easy one, which just returns the last value if there are more than one
parameter with the same name (I checked a bunch of libraries and using
the last of duplicates seemed to be more popular), and the advanced
one, which returns an array containing all of the values.

2) The origin attribute is now readonly.  Once I wired up the origin
attribute to the actual definition of how to compute the origin of a
URL, it became obvious that we don't want to support assigning to the
attribute.  In particular, it doesn't seems particularly meaningful to
assign the string "null" to the attribute even though that's a
perfectly reasonable value for the attribute to return.

3) I've added definitions for what the interface actually does.

In response to folks who think we should add these APIs to
HTMLAnchorElement and Location, I agree.  Currently, the draft is
written to refer to HTML5 for the definitions of the common elements,
but we could easily reverse that dependency or incorporate this API
into HTML5.

Adam

Received on Monday, 20 September 2010 05:04:01 UTC