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


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>

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.


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 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC