[whatwg] Review of the 3.16 section and the HTMLInputElementinterface

[Matthew Paul Thomas]

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/