Re: [whatwg] Review of the 3.16 section and the HTMLInputElementinterface

On Thu, May 15, 2008 at 5:04 PM, Matthew Paul Thomas <mpt@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 Friday, 16 May 2008 03:50:50 UTC