W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Re: [FileAPI] createObjectURL isReusable proposal

From: Charles Pritchard <chuck@jumis.com>
Date: Tue, 14 Feb 2012 05:39:54 -0800
Message-ID: <4F3A642A.2020907@jumis.com>
To: Bronislav Klučka <Bronislav.Klucka@bauglir.com>
CC: public-webapps@w3.org
On 2/14/2012 5:35 AM, Bronislav Klučka wrote:
>
>
> On 14.2.2012 5:56, Jonas Sicking wrote:
>> On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson<ian@hixie.ch>  wrote:
>>> On Thu, 2 Feb 2012, Arun Ranganathan wrote:
>>>> 2. Could we modify things so that img.src = blob is a reality? Mainly,
>>>> if we modify things for the *most common* use case, that could be 
>>>> useful
>>>> in mitigating some of our fears. Hixie, is this possible?
>>> Anything's possible, but I think the pain here would far outweigh the
>>> benefits. There would be some really hard questions to answer, too 
>>> (e.g.
>>> what would innerHTML return? If you copied such an image from a
>>> contentEditable section and pasted it lower down the same section, 
>>> would
>>> it still have the image?).
>> We could define that it returns an empty src attribute, which would
>> break the copy/paste example. That's the same behavior you'd get with
>> someone revoking the URL upon load anyway.
>>
>> / Jonas
>>
>
> The point of reusable Blob URL is the compatibility with regular URL, 
> not having reusable URL would create unpleasant dichotomy in data 
> manipulating...

What do you think of a global release mechanism? Such as 
URL.revokeAllObjectUrls();
Received on Tuesday, 14 February 2012 13:40:21 GMT

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