- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 14 Dec 2011 02:25:38 -0800
- To: Anne van Kesteren <annevk@opera.com>
- Cc: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Adrian Bateman <adrianba@microsoft.com>, Feras Moussa <ferasm@microsoft.com>
On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren <annevk@opera.com> wrote: > On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman <adrianba@microsoft.com> > wrote: >> >> At TPAC [1,2] I described our proposal for adding an isReusable flag to >> createObjectURL. A common pattern we have seen is the need for a blob URL >> for a single use (for example, loading into an <img> element) and then >> revoking the URL. This requires a fair amount of boilerplate code to >> handle the load/error events. >> >> createObjectURL is modified as follows: >> >> static DOMString createObjectURL(Blob blob, [optional] bool isReusable); >> >> The value of isReusable defaults to true if it is not supplied and this >> results in the behaviour documented for File API today. However, if you >> supply false for the flag then the first dereference of the URL revokes >> it. >> >> This means that you can do something like: >> >> imgElement.src = URL.createObjectURL(blob,false) >> >> and not worry about having to call URL.revokeObjectURL to release the >> Blob. > > > I think we should solve this by assigning an object directly to attributes > that take a URL. > > So instead you would get > > imgElement.src = blob > > which is much cleaner I think. (The content attribute would then be set to > "about:object-url" or some such.) The problem is that we have tons of APIs that deal with URLs in the form of strings. Not least the CSSOM which uses a lot of string concatenation. So we'd have to sign up for a very big task of changing all of these APIs so that they work with objects instead of strings. Speccing and getting that implemented will take a considerable amount of time. There's also things like .innerHTML which people often prefer over using the direct DOM API. Some of this is likely due to the pain that the DOM-API is, but I suspect even with a "perfect" DOM API we'd still see a lot of string usage due to it's ease of use. So I'm not convinced that the value/cost ratio of this proposed solution is high enough. / Jonas
Received on Wednesday, 14 December 2011 10:26:37 UTC