On Thu, 21 Oct 2010 19:47:08 +0200, Jonas Sicking <[email protected]> wrote:
On Thu, Oct 21, 2010 at 3:50 AM, Anne van Kesteren <[email protected]>
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/
