- From: Victor Costan <costan@gmail.com>
- Date: Fri, 7 Dec 2012 16:42:57 -0500
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg <whatwg@whatwg.org>
On Wed, Dec 5, 2012 at 12:11 PM, Ian Hickson <ian@hixie.ch> wrote: > On Wed, 5 Dec 2012, Victor Costan wrote: >> >> There was a thread on this mailing list discussing making it possible to >> set the file data behind an <input type="file"> element. >> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/thread.html#36140 >> >> The thread seems to have died down due to insufficient applications for >> the proposal. > > Actually the reason this thread hasn't gone anywhere is that there seems > to only be implementer interest from Chrome. > > See: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest Thank you very much for explaining! I can file a bug against Firefox, and argue for it. I think I would have an easier time making an argument if I knew how the API should look like. Can you please give me a hint as to which variant you'd be more likely to agree with? Mutable FileLists vs a way to put together a new FileList + writable files attribute on <input type="file">? File constructor taking a Blob + name vs having Blobs in a FileList? >> 1) This would make it possible to write JavaScript libraries that >> seamlessly scan the current page for <input type="file"> and add >> integration with Dropbox / Google Drive / Sky Drive etc. I claim that >> changing the <input> value is the easiest and most robust method of >> achieving this without requiring changes to the main application code. >> Asides from providing an easy path for developers to integrate online >> storage services into their apps, this change would make it easy to >> write bookmarklets / browser extensions that add this functionality to >> any Web application. > > It seems like this use case would be better handled by having the sites > offer an API to the browser, similar to Web Intents, for picking a file. > That way you wouldn't need to update each site -- every site would support > all the drive systems you use. > Yes, but that approach would require deeper application changes. I think that adding a couple of <script> tags next to an existing <input type="file"> is easier to implement. >> 2) If I can set the files attribute of an <input type="file">, I can >> write unit tests for any code that deals with such an <input>, such as >> XHR uploads. Tested code is less likely to break down as it is >> maintained, so it makes for a better Web. > > That's an interesting use case, indeed. Thank you! In general, read-only APIs make testing really hard :( >> 3) Browser extensions / bookmarklets could easily filter files being >> uploaded. For example, an extension could automatically resize pictures >> larger than a certain threshold by rendering them to an off-screen >> <canvas>. As another example, an extension could detect when huge files >> are uploaded to a Web mail client or forum, automatically upload them to >> Dropbox / Google Drive / Sky Drive, and replace them in the <input >> type="file"> with tiny ".url" files pointing to the real files. > > In general, browser extensions don't have to be handled by Web standard > APIs, so I'm not sure that's a compelling use case. I think it would be useful to have a drop-in JS library that can perform image resizing on the fly without requiring XHR-based form submission. >> With these applications in mind, I don't think FileList needs to accept >> Blobs. Instead, there should be an easy way to build a File out of a >> Blob and a file name. This capability seems to have been lost when >> BlobBuilder was deprecated by the Blob constructor. > > There are places where FileList definitely needs to be readonly, so I > don't think it makes sense to make it globally writable. but there could > be a MutableFileList or something. That feedback should be sent to the > list mentioned at the top of the File API spec. FileList doesn't have to be mutable if there is a FileList constructor that accepts File instances, or if the files attribute of <input type="file"> accepts an array of File instances and converts it into a FileList. I will start a discussion on the public-webapps@w3.org. For reference, they seem to be in favor of a File constructor. http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0692.html Thank you very much for your consideration, Victor
Received on Friday, 7 December 2012 21:43:44 UTC