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

Re: A URL API

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>
Message-ID: <op.vi6xjvrb64w2qv@anne-van-kesterens-macbook-pro.local>
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 GMT

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