W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2004

[whatwg] File Upload Control

From: Greg Kilwein <gkilwein@fbsdata.com>
Date: Thu, 26 Aug 2004 12:05:06 -0500
Message-ID: <059701c48b8e$d6f7d6c0$0b4aa8c0@gregkilwein>
> > Ian Hickson wrote:
> > > File upload controls should never be stylable. If they were stylable,
it
> > > would be too easy to trick users into uploading private files, by
making
> > > them think they were normal text fields, for example.
> >
> > How exactly would it make it any easier for a user to be tricked into
> > selecting and uploading a private file if there was no visible browse
button?
> > The user would just be forced to type the full path manually, rather
than
> > selecting it with a GUI, so they would still no they were selecting a
file.
>
> You'd be surprised how easy it is to trick users into typing things like
> that. For example:
>
>   Q3. What is the path to a Linux system's password file?
>       [                       ]
>
>   (( Submit Quiz ))

I say that disallowing styling of the file upload control is a dubious
"security" measure at best, as sites can currently obscure the browse button
(if it exists) by layering other items over the top of it, or by making sure
that the control is partially cut off on the side of the screen by using
script to reposition the element.  Or, consider this example (this works on
IE6 for Windows, for me, which would certainly fool the majority of web
users out there who fall in the "foolable" camp.  It might not work exactly
on every machine, but you can get the idea, and a motivated developer could
make this work with the majority of UAs and platforms):

Q3. What is the path to a Linux system's password file?
<div style="width:143px;overflow:hidden;height:30px;">
<input type="file" name="evil">
</div>
<input type="submit" value="Submit Quiz">

Given this example, I say the statement that file controls should not be
styled for security reasons is invalid, since they can already be massaged
to remove the browse button.  Since there already exists the ability to fool
the user, given my above example, why should they not be stylable?  I have
yet to hear a compelling argument for the inability to style the file upload
control.

If there were a standardized way to style this control, it would help the
appearance of web apps.  If we are to make web apps "first-rate citizens",
the ability to change even the simplest thing such as the font in the file
upload control would allow the ability to lend more uniformity to the
application.  Full styleability would be ideal.  Native apps have the
ability now to create any sort of file upload control using whatever style
is desired - why can't "first-rate" web apps?  That would make "first-rate"
web apps no longer first-rate.  The excuse that web application designers
would do ugly things with form controls given full style control is not a
valid reason to disallow the styling of the control, either.  Denying
developers the ability to create a horrible mess of a UI, by extension, also
denies developers the ability to create a better UI.

I believe that if one form control is styleable, they all should be.  UAs
can still feel free to ignore whatever style elements they don't wish to use
(Safari, for example, ignores colors and borders on buttons, but adheres to
the "width" element; their file upload control is radically different than
other UAs.  Yet, style="display:none" can be applied to the upload control).

There are three areas of a file upload control that should be available for
styling if the UA wishes:  1) The "choose a file" part (commonly a button,
but not always); 2) the name of the file (commonly a textbox, but not
always); and 3) the outer bounding box of the control itself (this would
exist for every file uploader).  At the very least, item 3 should be
defined.  I'm arguing that items 1 and 2 should be defined (but optional for
UAs to implement, as is the case with Safari), as well.

Greg
Received on Thursday, 26 August 2004 10:05:06 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:36 UTC