- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Fri, 3 May 2013 14:55:37 +0100
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Eric U <ericu@google.com>, Arun Ranganathan <arun@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>
On Thu, May 2, 2013 at 12:53 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> But if we can figure out this problem, then my proposal would be to
> add a new method which has a "nicer" name than createObjectURL as to
> encourage authors to use that and have fewer leaks.
Yeah, I've been thinking the same thing. URL.create(...) is available.
Or maybe URL.from() or some such.
> It actually has turned out to be surprisingly easy in Gecko. But I
> realize the same might not be true everywhere.
Can we have a description of this (and how it does not run into the
problems Glenn mentioned). I feel that I have an incomplete
understanding of what actually happens at the moment.
img.src = url
Will at least parse the URL. As you can synchronously request img.src
and it will return a serialization of the parsed URL (or the same
value in case parsing failed). Are any other algorithms synchronously
invoked?
img.style.backgroundImage = "url(" + url + ")"
Similarly seems to require (apparent) synchronous parsing.
Glenn has at times suggested we could make a pertinent reference to
the Blob object from the URL object you get from the parsing. That
might work, but requires some special casing of blob URLs and soon
mediastream URLs (and ...) in a thin wrapper around the URL parser
which all end points would need to use.
What am I missing?
--
http://annevankesteren.nl/
Received on Friday, 3 May 2013 13:56:08 UTC