- From: Anne van Kesteren <annevk@opera.com>
- Date: Fri, 17 Sep 2010 20:56:09 +0200
- To: "Adam Barth" <w3c@adambarth.com>, "Maciej Stachowiak" <mjs@apple.com>
- Cc: "Darin Fisher" <darin@chromium.org>, "Julian Reschke" <julian.reschke@gmx.de>, "Boris Zbarsky" <bzbarsky@mit.edu>, "WebApps WG" <public-webapps@w3.org>
On Fri, 17 Sep 2010 20:51:27 +0200, Maciej Stachowiak <mjs@apple.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). You could actually "just" use xml:base. > - 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. We have navigator.resolveURL(url) in HTML5. I believe that was mostly for Web Workers. Probably because in Workers you cannot have stray <a> elements, or maybe because we just forgot about using <a>... (Not really been involved in that discussion.) -- Anne van Kesteren http://annevankesteren.nl/
Received on Friday, 17 September 2010 18:56:50 UTC