- From: Jon Barnett <jonbarnett@gmail.com>
- Date: Thu, 15 May 2008 22:50:14 -0500
On Thu, May 15, 2008 at 5:04 PM, Matthew Paul Thomas <mpt at myrealbox.com> 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". Except for the needless sarcasm - we're on the same page here. > > 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. Is this the iphone's behavior? (earlier you said it doesn't implement <input type=file>, but here you're saying it's implemented 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. 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. > > 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. 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? > >> ... >> 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). >> ... > > Web Forms 2.0 already defines min= and max= attributes for this purpose. Thanks, I hadn't seen that. <input type=file max=n> where n is greater than 1 would allow for mutliple files. I hadn't seen that. -- Jon Barnett
Received on Thursday, 15 May 2008 20:50:14 UTC