A File interface, which includes readonly informational attributes about a file such as its name and its mediatype.

A FileError interface, which defines the error codes used by this specification.

The API to get access to selected files is trivial (document.getElementById("myFileInput").files.length etc) and then you can get the file data itself in various forms (data: URL, text, binary, Base64, new filedata:// URL).

It’s really nice to see that there is a good specification for the File API. It’s a bummer though that the Mozilla team hasn’t implemented it fully and doesn’t have support for the slice method this makes it very unpractical when you handle large files for example a video stream since it then loads the whole contents into memory before sending it using for example a XHR call.

@iliad: One could just hope that both the WebKit and Gecko teams implement this feature. The current state is that WebKit doesn’t have support for any of the file methods. You can just extract the name and the size of the selected files. Gecko has most of the methods but not one important one for slicing the files into smaller chunks. I hope both vendors implement the W3C spec soon and think about memory management this is an awesome concept and would remove the need for Flash or Gears for uploading many and large files.

I’d love to be able to upload a file via XHR, then be able to query that process for progress information.Note that I’d prefer this to callbacks, as it would give me more control over when the UI is updated.

does work on file ‘type’ will put pressure on browser developers to resolve 2GB limit bug? For now, trying to upload file larger than 2GB result with silent crash or bad headers (Content-Length below zero)..

Yay, finally another useful thing in HTML5 that Flash actually doesn’t do better.

Comment by Darkimmortal — August 12, 2009

I think the most important thing is to integrate this into XHR to ease all of the iframe hacks for uploading files asynchronously.

I would also vote that if there is a progress API that you can specify the call rate and the callback something like this:
var rate = 2000; // milliseconds between each report
loader.registerProgressListener(rate, function(uploadedBytes,totalBytes,bytesPerSecond){
//...
})

Progress events/status falls outside the scope of this article since that is not part of the File API, but the XmlHttpRequest API.

That said, I don’t agree with progress events, simply allowing the script to periodically poll the request would be simpler, and effectively the same thing.

Upload progress is something that should already be exposed in the browser. Primarily as a progress widget similar to the loading progress bars (which are largely fake, since total page size includes all the images, scripts etc.) The browser should know how big the request is, and how much data has been sent. It just needs to expose that information, visually or via JS.

This shouldn’t be limited to the request either. Responses should be accessible too. Access to data loaded, and the http size header would be nice as well, and not just for AJAX Requests. Frame, img, video, audio etc objects would be nice too. Potentially allowing for pretty pre-loaders for these elements.

I’d be interested in being able to access files as mime style packages. (similar to emails and MHTML.)

This would provide a low rent way to have multipart structured files. Of course the would make the API more complex since you’d want to be able to read each part individually. This would be useful for apps that want to load and save multipart data in a single file such that you didn’t need to prompt the user to select multiple files or embed and decode multiple files in a single file.

This is easily fakeable if the file is already an MHTML document, by reading as text and parsing. I’d be nice if this was baked in though.

Would make for a really simple shorthand for generating email attachments too.

Uploading files by drag and drop from the native OS to a programmatically defined destination area inside the browser window would be great. Maybe we could have a confirmation dialog to prevent accidental uploads and to make this feature’s security equivalent to the one of the standard file selection box.

XHR file upload and progress callbacks will be very useful. Progress callbacks should be available for any XHR request, not only for files.

A way to query progress even for non-XHR file uploads would also be useful but it could be skipped if the browser reports about the progress of the uploads of every single file.

@Deadmeat: access to local files is a matter of trust. The OS itself or any famous application running on your machine (Office, Photoshop, any web browser) could be sending a copy of all your files to a remote server right now. All you can do is trust your vendor or the users’ community, read the source code if available, monitor your Internet connection. The companies running web applications are usually way more obscure than the vendors of OS or mainstream applications so trust is lower. Flash and also Java (Silverlight as well?) can access files, webcam and microphone but only after prompting the user for permission and I’m sure you grant permission only to applications you trust. There are no reasons why JavaScript shouldn’t be able to do the same. The only problem I see is that it will lower the barrier to entry for attackers: there are probably less people that can write Flash, Java and Silverlight than there are that can write JavaScript. As a countermeasure permissions should be granted on a single file basis and/or variables and DOM elements getting content from local files should be marked as tainted and the browser should not be able to send their values to a remote server.