File API features in HTML5

On Wed, 14 May 2008, Samuel Santos wrote:
> On Mon, Feb 11, 2008 at 12:11 AM, Samuel Santos <samaxes@gmail.com> wrote:
> >
> > When developing a web application I can't usually rely on the 
> > languages configured on the user browser (sent through the 
> > Accept-Language). Often I need to send e-mail or sms notifications and 
> > I need to know the user preferred language, so I need to have it saved 
> > on the user profile on the database.
> >
> > The same applies to the application web interface. Not all the users 
> > want the default language of the application to be english, but few of 
> > them configure the languages in their browser. That causes the user to 
> > have a different language configured in their application's profile 
> > and in the browser. In summary, what I mean is that I can only trust 
> > the language the user has chosen in his profile and not in the 
> > language send by the browser.
> >
> > This is a problem for the input element with type="file". If the 
> > language selected in his profile is, e.g. portuguese, and the language 
> > in the browser is english (the default), he will see all the 
> > application in portuguese and the input file browse button text value 
> > will be in english.
>
> This issue seems to be a very recurring and still unsolved problem when 
> dealing with Web internationalization / multi-language Web Apps. I would 
> like to suggest this to be reviewed with an editor comment please.
> 
> Additionally, it's important if we could decorate separately the file 
> path text field and the browse button using CSS.

On Wed, 14 May 2008, Darin Adler wrote:
> 
> This wouldn't work well for Safari or WebKit. WebKit's <input type=file> 
> does not have a file path text field nor does it have a button with the 
> label "Browse" on it. The label is "Choose File" in WebKit.

On Thu, 15 May 2008, Boris Zbarsky wrote:
> Samuel Santos wrote:
> > I don't think this is a valid argument since you can change it anyway 
> > 
> > http://www.quirksmode.org/dom/inputfile.html
> 
> I should note that some consider this a (low priority, low severity) 
> security bug that should just be fixed (e.g. by disallowing opacity 
> styling on file inputs or some such).

On Thu, 15 May 2008, Jon Barnett wrote:
> 
> The Yahoo! UI toolkit [1] allows a developer to create a "browse" that 
> looks like whatever he wants it to and can be controlled by javascript 
> pretty much however he wants it to.  Flickr uses this (you have no log 
> in, so no link here).  It also has more robust features than <input 
> type=file>
>
> - the interface can have custom styles
> - the dialog can choose multiple files
> - the dialog can filter certain file types
> 
> That Yahoo widget uses Flash and Javascript to make all that happen. 
> Adobe isn't going to take this feature of Flash away (Javascript control 
> of a file dialog) and I wouldn't expect browsers to try to block it.
> 
> The W3C File Upload [2] draft allows for the something similar using 
> plain javascript without the requirement for Flash, and there are 
> already implementations in the wild.  That's just a generic Javascript 
> API - I can't imagine browsers trying to restrict how that looks on the 
> page.  Again,
> - the interface that have custom styles (anything with an onclick will do)
> - the dialog can choose multiple files
> 
> These aren't features you're going to take away from today's users of 
> popular web applications.  Those features are here to stay.  I don't see 
> how customizing the look of the file dialog's button is a security risk.  
> Sure, the button might say something malicious, but it still requires 
> the user to browser his local files, choose a file, and click "Open".
> 
> One problem with either the Yahoo widget or the File Upload draft is 
> that they both require Javascript to function.  If you want these 
> features to be accessible to non-Javascript enabled browsers, we'll need 
> to include it in HTML.  It would probably call for a new <input> type 
> with a more specific, flexible presentation (i.e. just a button that can 
> be styled with CSS)
> 
> If Javascript is as an acceptable requirement, another problem with 
> those solutions is that they require separate POSTs.  The Yahoo uploader 
> uses a separate request for each file.  The File Upload API has 
> functions like getDataAsHexBinary that, I guess, could put a file's data 
> into a hidden input field, but that data still wouldn't be uploaded the 
> same way regular <input type=file> is uploaded (as multipart/form-data 
> with headers for each file, etc).
> 
> It would be better for HTML to specify an accessible and clean way of 
> styling buttons for producing file dialogs than to force Samuel Santos 
> to use dirty CSS hacks, a proprietary tool, or an API that interfaces 
> with HTML forms in a clunky way.
> 
> [1] http://developer.yahoo.com/yui/uploader/
> [2] http://www.w3.org/TR/file-upload/

On Thu, 15 May 2008, Matthew Paul Thomas wrote:
> 
> Imagine that there is a popular mobile device with a Web browser. 
> Imagine further that this browser is widely used, despite having no 
> support for Flash, no support for W3C File Upload, and not even any 
> support for <input type="file">. I know, I know, this seems unrealistic, 
> because "those features are here to stay", but humor me here for a 
> moment. For ease of discussion, let's call this device the "iPhone".
> 
> Imagine further that this "iPhone" has no user-visible file system. It 
> stores music, but annoyingly, the device vendor doesn't want to let 
> people upload songs to Web sites. What the vendor *does* want to let 
> people do is upload photos to Web sites, so that they can use sites like 
> Flickr or even post photos to their Weblogs from the road.
> 
> So the "iPhone" vendor implements <input type="file"> just for photos. 
> It's rendered in a Web page as three components: (1) a button for taking 
> a new photo, (2) a button for choosing an existing photo, and (3) a 
> thumbnail of the selected photo. There's no "filename": that wouldn't 
> make any sense, because device has no user-visible files. And there's no 
> button labelled "Browse…": that wouldn't make any sense, because -- 
> well, shoot, that label's never made sense on any platform.
> 
> A Web author couldn't implement anything nearly as useful as this using 
> a new control with a "more specific, flexible presentation" -- and 
> they'd need JavaScript to even come close. The UA, on the other hand, 
> can customize the file upload control based on the accept= attribute 
> provided by the author, the presence or absence of a camera, whether a 
> camcorder is connected, whether a microphone is available, whether 
> available input devices are such that direct entry of a text document is 
> feasible, and so on, all regardless of whether JavaScript is available.
> 
> [...]
> 
> It's a security risk in those browsers where <input type="file"> 
> contains an editable text field, because a page could trick you into 
> typing the pathname of a confidential file into the field, and the 
> button would no longer warn you that it wasn't an innocent text field. 
> In browsers (such as Firefox 3, as Jonas just mentioned) where the field 
> is not editable, the button is safer to style -- but if you're assuming 
> the control contains only one button, you might produce ugly results on 
> devices where it has more.

On Thu, 15 May 2008, Jon Barnett wrote:
> 
> The interface for choosing a file isn't particularly important.  It's 
> the style/presentation of the button that triggers that interface that's 
> in question, or being able to create your own interface to trigger that 
> file-choosing interface.
>
> [...]
> 
> Sure, we agree that tricking a user into typing a filename is somewhat 
> of a security risk, and browsers have mitigated that.  My point was 
> "disguising" the button that triggers the file-choosing dialog box (or 
> web-page-like interface, if you will) is NOT a security issue.  It's 
> very possible to create a custom interface for triggering that dialog, 
> but all the solutions I know of are convoluted and don't interface well 
> with web forms.  For example, if I want just a plain blue, underlined 
> link (a la Flickr, "click here to upload your photos") to trigger that 
> "browse" dialog, I have to use something like Yahoo's widget or the File 
> Upload API.  Or, I have to use CSS hacks that are probably going to look 
> silly on an iPhone.  I only have a couple possible solutions in mind:
> 
> - Insist that <input type=file> always be rendered like <input 
> type=button> and therefore can be styled as such.  That's not such a 
> great solution for lots of reasons.
> 
> - Insist that the HTMLInputElement.click() method in Javascript trigger 
> the UAs file-choosing dialog.  I don't know any browsers that support 
> that, you know, for security reasons - never mind that there are two 
> other ways to already do that with Javascript today.  That would require 
> Javascript to function, but at least it degrades more gracefully than 
> depending on Flash or the File Upload API just to have a custom button.  
> The HTMLInputElement would stay intact, so you don't have to code two or 
> three separate methods of handling file uploads (see my note about 
> separate POST requests, etc.).  Plus it would be more feasible on a 
> device like the iPhone that may not support a whole new complex API (and 
> may never get Flash).
> 
> So, is there any reason for browsers to NOT support 
> HTMLInputElement.click() to trigger a file dialog?  Is it reasonable to 
> insist that they do?  Would that solve Samuel Santos' original concern 
> for wanting a custom, localized button that says "Upload a file" in his 
> site's native language?

I haven't changed the spec for this use case.

There some interest (and also a lot of objections) around providing an API 
to obtain a File object form script, without an <input type=file>. If this 
happens, it'll be part of the File API spec, so I recommend sending such 
feedback to the public-webapps list.

Regarding styling, that's a CSS issue. I recommend taking that to the 
www-style list.


On Tue, 21 Apr 2009, Alfonso Martínez de Lizarrondo wrote:
>
> The current definition for the dataTransfer that it's available when 
> some content is pasted into a web page is missing at least one 
> functionality that always makes users realize that they are using a web 
> page and not a desktop application: they can't copy and paste any 
> content from another program and automatically include those images, 
> they can't drop some files from their file manager into their editor and 
> get that file correctly placed on the server and linked/displayed.
> 
> That could be made possible if the dataTransfer object included an 
> attribute "files", so it behaves like an "invisible input type=file" 
> element has been added and its content are the files corresponding to 
> what is being pasted.

I've added a way to drag-and-drop files into HTML.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'