- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 6 Aug 2010 19:10:12 +0000 (UTC)
On Tue, 8 Jun 2010, Eitan Adler wrote: > > A lot of websites let you upload either from a file on your hard drive > or from a link on the web. Most of the time this is done by having two > different inputs: One for a file and the other for a URL. > > If there were some type of input like "upload' which will allow for > any complete input. > Something like > file:///home/eitan/file_to_upload.pdf > or > http://example.com/file.pdf > or > ftp://user:password at example.com/file.pdf > > It would then be the server's job to fetch the file unless the user > passed it a file:// scheme it which case the file would be provided by > the UI. As far as I can tell nothing stops a browser from doing this today with <input type=file>. Indeed, on Windows it's probably already supported since the default Open File dialog supports URLs. On Wed, 9 Jun 2010, Rob Evans wrote: > > I think an interesting addition to the input type=upload would be a > script-accessible progress value. Either as a percentage, or probably > more useful two values, one being the size of the upload and the other > being current bytes sent. I think it might make sense to expose file upload progress on a <form> to a same-origin server. It would be interesting to see how the equivalent feature in XMLHttpRequest is received before we add this, though. I've made a note of it. > Also whilst we're on the subject, how about allowing multiple files to > be selected from a single input element? This is in the spec now. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 6 August 2010 12:10:12 UTC