[whatwg] New URL Standard
kosmo.zb at gmail.com
Mon Sep 24 17:18:54 PDT 2012
On Mon, Sep 24, 2012 at 4:07 PM, Glenn Maynard <glenn at zewt.org> wrote:
> On Mon, Sep 24, 2012 at 12:30 PM, Tab Atkins Jr. <jackalmage at 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).
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 "
> 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
More information about the whatwg