W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2012

Re: [whatwg] New URL Standard

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 24 Sep 2012 18:07:48 -0500
Message-ID: <CABirCh8GgDnXj+5kn=mcGYibhV7AkgO4sJjMz=Kzn=yoKtg6fQ@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Alexandre Morgaut <Alexandre.Morgaut@4d.com>, whatwg <whatwg@whatwg.org>
On Mon, Sep 24, 2012 at 12:30 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> I suggest just making it a map from String->[String].  You probably
> want a little bit of magic - if the setter receives an array, replace
> the current value with it; anything else, stringify then wrap in an
> array and replace the current value.  The getter should return an
> empty array for non-existing params.  You should be able to set .query
> itself with an object, which empties out the map and then runs the
> setter over all the items.  Bam, every single methods is now obsolete.

When should this API guarantee that it round-trips URLs cleanly (aside from
quoting differences)?  For example, maintaining order in "a=1&b=2&a=1", and
representing things like "a=1&b" (no '=') and "a&&b" (no key at all).

Not round-tripping URLs might have annoying side-effects, like trying to
use history.replaceState to replace the path portion of the URL, and
unexpectedly having the query part of the URL get shuffled around or
changed in other ways.

Maybe it could guarantee that the query round-trips only if the value is
never modified (only assigned via the ctor or assigning to href), but once
you modify the query, the order becomes normalized and any other
non-round-trip side effects happen.

By the way, it would also be nice for the query part of this API to be
usable in isolation.  I often put query-like strings in the hash, resulting
in URLs like "
and it would be nice to be able to work with both of these with the same
interface.  That is, query = new URLQuery("a=b&c=d"); query["a"] = "x";
query.toString() == "a=x&c=d";

Glenn Maynard
Received on Monday, 24 September 2012 23:10:40 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:45 UTC