- From: Adrian Bateman <adrianba@microsoft.com>
- Date: Wed, 14 Dec 2011 16:34:23 +0000
- To: Jonas Sicking <jonas@sicking.cc>, Anne van Kesteren <annevk@opera.com>
- CC: "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>, Feras Moussa <ferasm@microsoft.com>
On Wednesday, December 14, 2011 2:26 AM, Jonas Sicking wrote: > 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: > >> 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. I agree - I forgot to mention the CSSOM issue in my previous reply but it is something we've thought about too. Adrian.
Received on Wednesday, 14 December 2011 17:45:03 UTC