[whatwg] Proposal: API to ask the user for a file

[JC]

> On Mon, Apr 29, 2013 at 1:41 PM, Ian Hickson <ian at hixie.ch> wrote:

>>  On Mon, 29 Apr 2013, JC wrote:
>>> 
>>>  So far the only way to ask a user to select a file (e.g. to upload an
>>>  attachment in a mail client) without showing the ugly "file 
> input" UI is
>>>  to create one of these elements, hide it somehow, and invoke the 
> "click"
>>>  method on it and listen for the "changed" event.
>> 
>>  You can also just accept a drag-and-dropped file.

I have that too, but there's always going to be a manager who thinks that drag and drop is not good enough or not user friendly or they really want to see an upload button (and I happen to have one of those managers).

>>  Having the <input type=file> UI hidden is probably not supposed to be
>>  possible (though it's hard for us to stop it), because it means you can
>>  trick people into clicking the button and bringing up the dialog, which
>>  can, if you know what browser/OS they're using, let you in some cases
>>  trick them into uploading a particular file. (It's gotten harder with
>>  browsers going away from allowing arbitrary text input into that
>>  control, though, so this might no longer be that big a deal.)
> 
> I think all modern browsers intentionally let webpages create custom
> UIs for <input type=file> by completely hiding the <input> and then
> rendering a custom UI using various <div> and <span> tags. When the
> custom UI is clicked the page calls myInputElement.click() in order to
> bring up the file picker UI.
> 
> Gecko contains some anti-annoyance protections as to prevent the page
> from spawning file picker dialogs indefinitely. This is done by
> hooking up <input type=file>.click() to popup blocking infrastructure.
> 
> So the API being requested here is actually available. But in a really
> ugly way through the HTMLInputElement interface.

Yes, that's what I said in my proposal.

> But I don't really buy the argument that we should supply a new one
> because the existing API isn't "reliably available". If the 
> current
> API is problematic because there is no way to check if it works, then
> I'd prefer to add a way to check if it works, rather than adding a
> whole new API.


I guess I should have mention too that the existing API is not only unreliable but also very inconvenient. Since the trick depends on the "changed" event and there's no official way to clear the list of files selected the last time, in order to ensure that the event is fired if the same file is selected again the element has to be removed and replaced by a new one every time the user selects a file, that additional trick is documented here: http://stackoverflow.com/questions/10214947/upload-files-using-input-type-file-field-with-change-event-not-always-firin (and I was neither the person who asked or answered that question, so there's more people struggling with this issue).

-- 
JC