- From: Matthew Paul Thomas <mpt@myrealbox.com>
- Date: Thu, 15 May 2008 23:04:19 +0100
On May 15, 2008, at 8:33 PM, 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. > ... > 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. > ... > These aren't features you're going to take away from today's users of > popular web applications. Those features are here to stay. 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". > ... > 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) 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. > 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". 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. > ... > 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. Cheers -- Matthew Paul Thomas http://mpt.net.nz/
Received on Thursday, 15 May 2008 15:04:19 UTC