- From: Devdatta Akhawe <dev.akhawe@gmail.com>
- Date: Sun, 19 Sep 2010 17:03:25 -0700
- 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 UTC