W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: A URL API

From: Devdatta Akhawe <dev.akhawe@gmail.com>
Date: Sun, 19 Sep 2010 17:03:25 -0700
Message-ID: <AANLkTi=Mhqnd5Xwp1yEr53Wh_-cV3O7PKAZsGDKZM+JY@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>, WebApps WG <public-webapps@w3.org>, Garrett Smith <dhtmlkitchen@gmail.com>
hi

Is the word 'hash' for fragment identifiers common? I personally
prefer the attribute being called 'fragment' or 'fragmentID' over
'hash' - its the standard afaik in all the RFCs.

regards
devdatta

On 19 September 2010 15:47, Joćo Eiras <joao.eiras@gmail.com> wrote:
>
>> That would be different behavior than what Location and HTMLAnchorElement
>> do; they unescape various componenents. Is the benefit worth the divergence?
>>
>> 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...)
>> - Read search parameters conveniently without parsing.
>>
>> 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.
>>
>
> I idea too. I would rather extend "Location" to include these features, so
> they would be immediately available in links and the location object. And
> make Location into a constructor "new Location(url, base)"
>
>
Received on Monday, 20 September 2010 00:04:18 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:40 GMT