- From: Jonas Sicking <jonas@sicking.cc>
- Date: Tue, 19 Oct 2010 18:15:13 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Michael Nordman <michaeln@google.com>, arun@mozilla.com, public-webapps <public-webapps@w3.org>, Arthur Barstow <art.barstow@nokia.com>, Adam Barth <abarth@gmail.com>, Darin Fisher <darin@google.com>
On Tue, Oct 19, 2010 at 1:20 AM, Anne van Kesteren <annevk@opera.com> wrote: > On Tue, 19 Oct 2010 02:30:39 +0200, Jonas Sicking <jonas@sicking.cc> wrote: >> >> I agree. Another thing that is nice about the window.*BlobURL() API is >> that it makes it clear which origin the created url will have. I.e. >> the origin of the window which it's called on. >> >> We could maintain that even if we used a URL constructor by saying >> that it's tied to the window whose .URL property was used as >> constructor, but it makes it a much more indirect connection. > > It is not any less direct than how it works for new XMLHttpRequest, new > Worker, new EventSource, and any other number of constructors where URLs are > somehow involved in the objects they create. I do not really see why new URL > would be special here. I would say there is one more level of indirection, since people won't use the URL object, but rather the return value from its .href property. Additionally, I don't see what the value is of getting a URL object for a blob: url is? URLs are mostly useful when resolving relative references, but that never works for blob: urls. So we'd force people to always create a URL object and immediately throw it away. Another downside is that we lose the symmetry of createObjectURL/revokeObjectURL. It's still unclear where you are proposing the revoke function would be, but I can't think of any syntax which would have symmetry with a constructor. / Jonas
Received on Wednesday, 20 October 2010 01:16:07 UTC