W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

Re: [FileAPI] createObjectURL isReusable proposal

From: Anne van Kesteren <annevk@opera.com>
Date: Fri, 16 Dec 2011 12:08:00 +0100
To: public-webapps@w3.org
Message-ID: <op.v6kw7mc864w2qv@annevk-macbookpro.local>
On Wed, 14 Dec 2011 11:25:38 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
> On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren <annevk@opera.com>  
> wrote:
>> 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
>
> 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.

I do think that is something that we should do and as I understand it this  
is what developers want as well. In addition, as Charles Pritchard said  
elsewhere in this thread: "Using automatic revocation with CSS makes no  
sense at all, I think the use here is simply for one-time img.src setters."


> 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.

The proposed API is significantly more complex for what is likely to be  
the common case and is also more complex than the basic usage of  
createObjectURL(). So only if you are an extremely competent programmer  
you will do the right thing here. I think that is very bad design.


-- 
Anne van Kesteren
http://annevankesteren.nl/
Received on Friday, 16 December 2011 11:09:01 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:49 GMT