Re: File API Feedback

On Thu, 18 Jun 2009, Arun Ranganathan wrote:
> >
> > I think FileDialog is a bad idea. We already have UI for selecting 
> > multiple files: <input type=file multiple>. (And soon with 
> > DataTransfer.files we have a second one.) I would much rather wait 
> > with FileDialog until it is very clear that we need it. It seems to me 
> > that <input type=file multiple>, the ability to expose files to 
> > ECMAScript, and the ability to upload files asynchronously using 
> > XMLHttpRequest is pretty much what applications are asking for. The 
> > motivation for this feature seems therefore to be purely about UI, 
> > which we should try to solve with CSS. There is no need to have 
> > duplicate functionality here.
>
> Today, well-known web applications leverage Flash for uploading content, 
> since what browsers do by default when prompted by <input 
> type="file"...> isn't desirable to these applications (with few 
> exceptions).

I spoke with the developers of one of these Well-Known Web Applications, 
and they didn't even _mention_ the styling difficulties of <input 
type=file> as one of the reasons for using Flash here. The feature 
requests were:

 - multiselection of photos
 - file upload progress
 - dnd of files
 - local display of images prior to uploading them
 - filtering by file type (image vs video vs office docs etc)
 - selecting or uploading a whole folder at once
 - resuming uploads after browser crash

After I prompted them, they said styling of <input type=file> would be ok 
too, at least in the way that other form controls are stylable.

Therefore I'd rather we didn't include FileDialog yet.

As far as I can tell the features above are handled by File, FileList, and 
simple additions to HTML5:

 - multiselection of photos
    -- we have <input type=file multiple> already

 - file upload progress
    -- adding File support to XHR2 addresses this

 - dnd of files
    -- adding a .files attribute to DataTransfer addresses this

 - local display of images prior to uploading them
    -- see below

 - filtering by file type (image vs video vs office docs etc)
    -- we have <input type=file accept=""> already

 - selecting or uploading a whole folder at once
    -- <input type=file multiple> can support many files from a folder

 - resuming uploads after browser crash
    -- adding File support to Database or LocalStorage would address this

Local display of images before uploading them requires being able to take 
a File object and poke it into parts of the platform that currently only 
take URLs. I suggest that the way we address this is by adding an API to a 
File object that returns a URL like this:

   scheme:uuid

...where "scheme" is some new scheme, and uuid is some unique number. Each 
URL in this scheme would have an intrinsic origin that is equal to the 
origin of the script context (the "first script" in HTML5 terms) that 
invoked the API to get the URL. This URL could then be passed around as a 
string and would be treated as a resource from the same origin as that 
script, and could thus be used with <img> and <canvas> and so on.

This would just need a File.getAsURL() method that mints the URL and 
returns it. The URLs would have some defined lifetime (e.g. same as the 
Document, or same as the session, or same as the browser, or something).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 18 June 2009 22:44:13 UTC