- From: Eric Uhrhane <ericu@google.com>
- Date: Thu, 11 Nov 2010 11:18:17 -0800
- To: Jonas Sicking <jonas@sicking.cc>
- Cc: Arun Ranganathan <aranganathan@mozilla.com>, Web Applications Working Group WG <public-webapps@w3.org>, Jian Li <jianli@chromium.org>
On Thu, Nov 11, 2010 at 10:02 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> On Thu, Nov 11, 2010 at 8:52 AM, Arun Ranganathan
> <aranganathan@mozilla.com> wrote:
>> At the recent Technical Plenary and All WG Meetings in Lyon, File API[1] was discussed, and there are some take away action items that I minuted for myself for File API, but I'm not sure they are reflected in ACTION items, etc. From my own notes:
>>
>> Essentially, strong opinions were voiced against having top-level methods createObjectURL and revokeObjectURL. So the biggest change was to introduce a new top-level object (ObjectURL) which would have methods to obtain a string Blob URI. This removes the need for a revocation mechanism, since now the ObjectURL object (which would take as a constructor the Blob object) would oversee lifetime issues. This is a big change, but potentially one that allows us to work with the emerging URL API (which hopefully is going somewhere).
>
> Actually, this was a brain-fart on my part. What was suggested was
> that we simply allow:
>
> img.src = myFile;
> img.src = myBlob;
> img.src = myFutureStream;
> img.src = "http://www.sweden.se/ABBA.jpg";
>
> These things could be implemented without lifetime worries.
>
> What we might need is a IDL construct so that a specification can just say
>
> interface HTMLImageElement {
> ...
> attribute URLThingamajig src;
> ...
> };
>
> Which would automatically define that it accepts files/blobs/strings.
> And gives us a central place to update when we want to add streams and
> other things.
While this is a clean API, it doesn't work for passing URLs to
plugins, and it doesn't work when folks construct a bunch of DOM via
innerHTML. And if you add a way to get a string from one of these
objects, you're back with the lifetime problem again.
Received on Thursday, 11 November 2010 19:19:04 UTC