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

Re: [whatwg] New URL Standard

From: David Sheets <kosmo.zb@gmail.com>
Date: Mon, 24 Sep 2012 17:18:54 -0700
Message-ID: <CAAWM5TwS0GuLGhnRJvx318qVsTv4ighRQg-2--cLOLQeQYA0gA@mail.gmail.com>
To: Glenn Maynard <glenn@zewt.org>
Cc: Alexandre Morgaut <Alexandre.Morgaut@4d.com>, whatwg <whatwg@whatwg.org>, "Tab Atkins Jr." <jackalmage@gmail.com>
On Mon, Sep 24, 2012 at 4:07 PM, Glenn Maynard <glenn@zewt.org> wrote:
> 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).

Always. The appropriate interface is (string * string?) list. Id est,
an association list of keys and nullable values (null is
key-without-value and empty string is empty-value). If you prefer to
not use a nullable value and don't like tuple representations in JS,
you could use type: string list list





where I've assumed that values after the second are concatenated with
commas (but it could be semicolons or some other separator).

Unfortunately, JavaScript does not have any lightweight product types
so a decision like this is necessary.

> 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.

That would be unacceptably broken.

> 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.

Why can't as much information as possible be preserved? There exist
many URI manipulation libraries that support maximal preservation.

> 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 "
> http://example.com/server/side/path?server-side-query=1#client/side/path?client-side-query=1",
> 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";

Is this not already supported by creating a new URL which contains
only a relative query part?

Like: query = new URL("?a=b&c=d"); query.query["a"] = "x";
query.toString() == "?a=x&c=d";

Why is a new interface necessary?

> --
> Glenn Maynard
Received on Tuesday, 25 September 2012 00:22:21 UTC

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