[whatwg] Review of the 3.16 section and the HTMLInputElementinterface
Matthew Paul Thomas
mpt at myrealbox.com
Thu May 15 15:04:19 PDT 2008
On May 15, 2008, at 8:33 PM, Jon Barnett wrote:
> The Yahoo! UI toolkit  allows a developer to create a "browse" that
> pretty much however he wants it to.
> control of a file dialog) and I wouldn't expect browsers to try to
> block it.
> The W3C File Upload  draft allows for the something similar using
> 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
> One problem with either the Yahoo widget or the File Upload draft is
> 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
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
> 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.
> 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.
Matthew Paul Thomas
More information about the whatwg