Re: createBlobURL

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

Right.


> 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
http://annevankesteren.nl/

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