- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Wed, 14 Dec 2011 16:27:46 +0000
- To: Anne van Kesteren <annevk@opera.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
- CC: Feras Moussa <ferasm@microsoft.com>
On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote: > On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman > <adrianba@microsoft.com> wrote: > > 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.) I've seen this discussed before. I'm not overly enamoured with this approach. Here are some of the reasons: 1. We have to change these properties to be of type 'any' and it's not obvious what impact that will have. 2. It involves making substantial changes to code flows that source content, which at least for us, would mean a fair amount of code churn. 3. It's not very obvious what the lifetime of the blob should be if it goes out of scope after this happens. We can certainly talk through some of these issues, though the amount of work we'd need to do doesn't go down. Our proposal is a small change to the lifetime management of the Blob URL and was relatively simple (for us) to implement. In our experience, createObjectURL is a good broker in web developers minds for switching from object to URL space. Cheers, Adrian.
Received on Wednesday, 14 December 2011 17:03:34 UTC