W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: createBlobURL

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 25 Oct 2010 15:09:18 +0200
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: "Arun Ranganathan" <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>
Message-ID: <op.vk4utrgt64w2qv@anne-van-kesterens-macbook-pro.local>
On Thu, 21 Oct 2010 19:47:08 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Oct 21, 2010 at 3:50 AM, Anne van Kesteren <annevk@opera.com>  
> wrote:
>> If that is the only real solution I suggest we do that. We can create  
>> some kind of DOMURL type which is either a DOMString or a  
>> URL/Blob/something and change the relevant APIs.
> This means that you can't use File objects together with things like
> .innerHTML (neither the getter nor setter) or things like
> CSSStyleDeclaration.background. Actually, it doesn't even work with
> CSSStyleDeclaration.backgroundImage since it can be a list of URLs.
> And with the CSS Image Values spec [1] it can be something much more
> complex.

It does not work with backgroundImage either way, as the syntax is not  
just a URL represented as a string, but a special kind of CSS URL string.

> If we don't want to use blob-URLs at all, we have to track down every
> single DOM property which deals with URLs and:
> A. Make sure that it doesn't use strings where URLs is part of the
> string (like .innerHTML or CSSStyleDeclaration.background). If it
> does, create a new object model that breaks down the string into
> components where the URL is a separate component.
> B. Make it take a DOMURL instead of a DOMString


> While I agree that memory management is a horrible thing to thrust
> upon developers, I really don't see an option here. It would
> complicate matters hugely in cases like
> CSSStyleDeclaration.backgroundImage. Can you even make a proposal for
> what the object model would look like which would work for [1]?

The CSS WG is working on an a better object model for CSS values that  
would cover that case.

> And as stated before, I think a hugely mitigating factor here is that
> the amount of memory leaked is very small.

But not small enough apparently to simply not bother with a way of  
cleaning it up.

> What I think we should do is to fine the places where people are most
> likely to use blob-urls and in those cases change DOMString to DOMURL.
> Such as HTMLImageElement.src like Darin proposes. But for the
> remaining places keep createObjectURL/revokeObjectURL. I would imagine
> that by just fixing a handful of properties we can cover 95% of the
> use cases and make those not require the author to do memory
> management.

95% seems way higher than our typical 80/20 goal. Why do we want to even  
bother with covering the other cases? We could start out with just DOMURL  
and if there is a real pressing need for more only then introduce those  
methods instead of doing everything right away.

> [1] http://dev.w3.org/csswg/css3-images/

Anne van Kesteren
Received on Monday, 25 October 2010 13:10:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC