Re: [whatwg] input type=upload (not just files) proposal
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:passw...@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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] input type=upload (not just files) proposal
On Fri, Aug 6, 2010 at 12:10 PM, Ian Hickson i...@hixie.ch wrote: 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. Just as a note, I would murder people for this ability. (The XHR ability is great as well, but having it even simpler is always better.) ~TJ
Re: [whatwg] input type=upload (not just files) proposal
On Fri, Aug 6, 2010 at 3:10 PM, Ian Hickson i...@hixie.ch wrote: 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. I also want to chip in that this would be really really awesome. It would be much less pressing if browsers could just be persuaded to add prominent native UI for this, of course . . .
Re: [whatwg] input type=upload (not just files) proposal
Forgive me if this has already been discussed... I cannot find it on the current working draft spec... 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. Is this already in the spec somewhere? I can't find anything... Also whilst we're on the subject, how about allowing multiple files to be selected from a single input element? -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Eitan Adler Sent: 08 June 2010 17:10 To: Lachlan Hunt Cc: wha...@whatwg.org; Simpson, Grant Leyton Subject: Re: [whatwg] input type=upload (not just files) proposal My understanding of the proposal is that given this particular control, the browser would provide an interface for either selecting a local file or entering a URL. If a file is selected, the file is uploaded as normal, equivalent to input type=file name=foo. Otherwise, if a URL is entered, the field is instead submitted as text, equivalent to input type=url name=foo. The server would then determine whether the foo field that was submitted was a file upload or a text field value, and if it were a text field, then it would supposedly be treated as a URL that should then be fetched. Eitan, have I understood your proposal correctly? Yes - exactly. -- Eitan Adler
Re: [whatwg] input type=upload (not just files) proposal
On Wed, Jun 9, 2010 at 5:22 AM, Rob Evans r...@mtn-i.com 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. If you are uploading by reference to URL (which presumably the server would fetch to save bandwidth) then progress information is probably not something that can easily be exposed by the HTML interface. You might want to use an out-of-band ajax-style channel with javascript to show progress instead. Also whilst we're on the subject, how about allowing multiple files to be selected from a single input element? That's been in there since HTML 3.2, I believe, and was implemented by some browsers (IE 5-8?). User interface concerns almost always end up preferring dynamic form behaviors, with variable numbers of input type=file elements added and removed on an as-needed basis before the form is submitted.
Re: [whatwg] input type=upload (not just files) proposal
If you are uploading by reference to URL (which presumably the server would fetch to save bandwidth) then progress information is probably not something that can easily be exposed by the HTML interface. You might want to use an out-of-band ajax-style channel with javascript to show progress instead. Indeed, when referencing a URL I don't think progress bars are much of an issue, but when dealing with a local file upload it would be great to have those values exposed to scripts! I hate having to poll the server for a progress update... it's so 1990. Or has this already been exposed to scripts... am I behind the times? So much to keep up with! That's been in there since HTML 3.2, I believe, and was implemented by some browsers (IE 5-8?). User interface concerns almost always end up preferring dynamic form behaviors, with variable numbers of input type=file elements added and removed on an as-needed basis before the form is submitted. I guess it's a matter of preference, but if you're uploading a load of images for instance, it gets tiresome having to keep clicking select file on every new input element. I wasn't aware that IE had implemented multiple file selection inside a single element however I would never have noticed anyway as I shun IE and avoid it like the plague. -Original Message- From: James Salsman [mailto:jsals...@gmail.com] Sent: 09 June 2010 13:47 To: Rob Evans; whatwg@lists.whatwg.org Subject: Re: [whatwg] input type=upload (not just files) proposal On Wed, Jun 9, 2010 at 5:22 AM, Rob Evans r...@mtn-i.com 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. If you are uploading by reference to URL (which presumably the server would fetch to save bandwidth) then progress information is probably not something that can easily be exposed by the HTML interface. You might want to use an out-of-band ajax-style channel with javascript to show progress instead. Also whilst we're on the subject, how about allowing multiple files to be selected from a single input element? That's been in there since HTML 3.2, I believe, and was implemented by some browsers (IE 5-8?). User interface concerns almost always end up preferring dynamic form behaviors, with variable numbers of input type=file elements added and removed on an as-needed basis before the form is submitted.
[whatwg] input type=upload (not just files) proposal
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:passw...@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. -- Eitan Adler
Re: [whatwg] input type=upload (not just files) proposal
Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote: 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.
Re: [whatwg] input type=upload (not just files) proposal
On Tue, Jun 8, 2010 at 5:37 PM, Simpson, Grant Leyton glsim...@indiana.edu wrote: Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote: 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. I imagine this would be a UI decision - not one made by the spec. However I, with very limited experience in UI creation, am envisioning a dialog box as you mention. Another option would be to have buttons to the side of the textbox one that has a web icon and another that has a folder icon. -- Eitan Adler
Re: [whatwg] input type=upload (not just files) proposal
On Tue, 2010-06-08 at 10:37 -0400, Simpson, Grant Leyton wrote: Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote: 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. I can see how this might work, but in theory it would be more difficult than it sounds. For example, passing an FTP uri would only work if that FTP server allowed anonymous access, as you wouldn't want to pass your own FTP access credentials to an unknown server. The local machine could determine if the FTP server they are giving a file reference to allows anonymous access I guess, and in cases where the FTP server doesn't, then it could behave like the KIO slaves in KDE, which allow local mapping of files at remote locations, such as SMB, FTP, SFTP, SVN, etc. But this is something that can only really be offered at the operating system level. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] input type=upload (not just files) proposal
O.K. Just wanted to clarify. With this sort of dialog in mind, I like your proposal. (I find it unrealistic to think that the average user would write out file://... but maybe I am mistaken.) However, I see one possible issue. Some apps provide the means to work with local files, URLs, and direct text input (such as the W3C's validator: http://validator.w3.org/). Might others expand your suggestion to include the direct text option? I don't have an opinion on that other than to say that the appropriate balance between utility and complexity would need to be found. On Jun 8, 2010, at 10:45 AM, Eitan Adler wrote: On Tue, Jun 8, 2010 at 5:37 PM, Simpson, Grant Leyton glsim...@indiana.edu wrote: Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote: 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. I imagine this would be a UI decision - not one made by the spec. However I, with very limited experience in UI creation, am envisioning a dialog box as you mention. Another option would be to have buttons to the side of the textbox one that has a web icon and another that has a folder icon. -- Eitan Adler
Re: [whatwg] input type=upload (not just files) proposal
On Tue, Jun 8, 2010 at 10:47 AM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: On Tue, 2010-06-08 at 10:37 -0400, Simpson, Grant Leyton wrote: Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote: 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. I can see how this might work, but in theory it would be more difficult than it sounds. For example, passing an FTP uri would only work if that FTP server allowed anonymous access, as you wouldn't want to pass your own FTP access credentials to an unknown server. Or the UA could fetch the remote resource and then re-transfer it, as is sometimes an option on desktop mail clients when attaching a URL (attach page vs attach link, or similar). Then it's just a UA issue, since the client can do that for any file input, and could even permit creating one from the clipboard. Mike
Re: [whatwg] input type=upload (not just files) proposal
On 2010-06-08 16:37, Simpson, Grant Leyton wrote: Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? My understanding of the proposal is that given this particular control, the browser would provide an interface for either selecting a local file or entering a URL. If a file is selected, the file is uploaded as normal, equivalent to input type=file name=foo. Otherwise, if a URL is entered, the field is instead submitted as text, equivalent to input type=url name=foo. The server would then determine whether the foo field that was submitted was a file upload or a text field value, and if it were a text field, then it would supposedly be treated as a URL that should then be fetched. Eitan, have I understood your proposal correctly? -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [whatwg] input type=upload (not just files) proposal
On Tue, 2010-06-08 at 10:58 -0400, Mike Shaver wrote: On Tue, Jun 8, 2010 at 10:47 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: On Tue, 2010-06-08 at 10:37 -0400, Simpson, Grant Leyton wrote: Are you wanting the user to manually enter the filename, including the file:// scheme? If not, are you envisioning the file dialog box to provide a choice between selecting local files and entering an http/ftp url? On Jun 8, 2010, at 10:32 AM, Eitan Adler wrote: 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. I can see how this might work, but in theory it would be more difficult than it sounds. For example, passing an FTP uri would only work if that FTP server allowed anonymous access, as you wouldn't want to pass your own FTP access credentials to an unknown server. Or the UA could fetch the remote resource and then re-transfer it, as is sometimes an option on desktop mail clients when attaching a URL (attach page vs attach link, or similar). Then it's just a UA issue, since the client can do that for any file input, and could even permit creating one from the clipboard. Mike Yes, and the rest of my email said that. KIO slaves on KDE work just like that. It's not something that I think a user agent can easily just add in, but something that needs to be supported at the OS level. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] input type=upload (not just files) proposal
On Tue, Jun 8, 2010 at 11:02 AM, Ashley Sheridan a...@ashleysheridan.co.ukwrote: Yes, and the rest of my email said that. Sorry, I am not familiar with KIO, and didn't see the need for OS support. KIO slaves on KDE work just like that. It's not something that I think a user agent can easily just add in, but something that needs to be supported at the OS level. I'm not sure why -- if the UA can save the resource to disk, and it can upload files from disk to the site, then it can do all the things required. It could optimize by chaining the streams together so it didn't have to buffer the whole resource on disk, but an uploaded file is just a bunch of bytes, so I don't think the OS needs to provide any sendfile-like magic. I'd actually be a little surprised if there wasn't a Firefox add-on that permitted this already, though overlaying the native file dialog is sort of tricky I guess... Mike
Re: [whatwg] input type=upload (not just files) proposal
On Tue, 2010-06-08 at 11:13 -0400, Mike Shaver wrote: On Tue, Jun 8, 2010 at 11:02 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: Yes, and the rest of my email said that. Sorry, I am not familiar with KIO, and didn't see the need for OS support. KIO slaves on KDE work just like that. It's not something that I think a user agent can easily just add in, but something that needs to be supported at the OS level. I'm not sure why -- if the UA can save the resource to disk, and it can upload files from disk to the site, then it can do all the things required. It could optimize by chaining the streams together so it didn't have to buffer the whole resource on disk, but an uploaded file is just a bunch of bytes, so I don't think the OS needs to provide any sendfile-like magic. I'd actually be a little surprised if there wasn't a Firefox add-on that permitted this already, though overlaying the native file dialog is sort of tricky I guess... Mike Because if it wasn't supported at the OS level, we would be back into the bad old days where each and every program had to reinvent the wheel for file dialogues, and no doubt every browser would have it's own unique way of presenting connecting to a remote resource. Not only that, but when implemented, you'd have different browsers implementing different subsets of connectivity. Some will offer only FTP, others will offer FTP and SFTP, others might offer FTP and SVN only. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] input type=upload (not just files) proposal
My understanding of the proposal is that given this particular control, the browser would provide an interface for either selecting a local file or entering a URL. If a file is selected, the file is uploaded as normal, equivalent to input type=file name=foo. Otherwise, if a URL is entered, the field is instead submitted as text, equivalent to input type=url name=foo. The server would then determine whether the foo field that was submitted was a file upload or a text field value, and if it were a text field, then it would supposedly be treated as a URL that should then be fetched. Eitan, have I understood your proposal correctly? Yes - exactly. -- Eitan Adler
