Closed Bug 52500 (input[type=file]) Opened 24 years ago Closed 11 years ago

Make regular CSS properties apply on <input type='file'>

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla24
Tracking Flags:
Tracking Status
firefox21 --- unaffected
firefox22 + verified
firefox23 + verified
firefox24 --- verified

People

(Reporter: thorne, Assigned: mounir)

References

(Blocks 1 open bug)

Details

(4 keywords)

Attachments

(20 files)

Test case - file input with border, padding, margin
279 bytes, text/html
Details
Poor rendering of Input type FILE with CSS Styles applied
193.35 KB, image/jpeg
Details
class in stylesheet, radiobutton doesn't show
20.11 KB, image/jpeg
Details
INPUT TYPE="file" testcase (with accept and style)
1.18 KB, text/html
Details
Testcase behavior in Moz0.9 and IE5.5
2.35 KB, image/png
Details
Inconsistency between 'input' and 'file' field sizes
381 bytes, text/html
Details
Testcase Moz 0.9.9 vs. IE 6
38.88 KB, image/gif
Details
Current display of input type="file" element with various styles
11.67 KB, image/png
Details
Alternative method for styling input type=file
12.08 KB, text/html
Details
Alternative on styles
2.44 KB, text/html
Details
The width is not rendered correctly
87 bytes, text/html
Details
error in width; redvsblue.com
5.56 KB, image/png
Details
suggested behaviour
3.69 KB, image/png
Details
Background-image doesn't work on file input either
15.75 KB, image/png
Details
fileinput background color ff2 vs ff3
29.01 KB, image/png
Details
Safar file input styling
25.56 KB, image/png
Details
css width property — bright, easy-to-understand testcase
481 bytes, text/html
Details
css width property — screenshot (FF3.0b5)
41.34 KB, image/png
Details
How the widths of the fields should look. Mockup made in The Gimp.
40.79 KB, image/png
Details
Patch
11.31 KB, patch
bzbarsky
: review+
lsblakk
: approval-mozilla-aurora+
lsblakk
: approval-mozilla-beta+
Details | Diff | Splinter Review 
Really wack rendering of a INPUT TYPE FILE form element when styles such as
border-style, border-width and width have been applied to it
mthorne@nf.sympatico.ca - could you attach a screenshot and/or a testcase
please?
Yeah, no kidding. Testcase coming up.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
QA Contact: ckritzer → py8ieh=bugzilla
Hardware: PC → All
Target Milestone: --- → Future
Keywords: css-moz, css1
*** Bug 52813 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Summary: CSS Styles applied to INPUT TYPE FILE → [FILE]CSS Styles applied to INPUT TYPE FILE
*** Bug 65597 has been marked as a duplicate of this bug. ***
Blocks: 77878
Here's my own experience with this bug:

Procedure: View the testcase.

Expected: Since the behavior for the browse button is undefined by any W3C
standard, you can't really be sure what to expect out of this. The best way
would probably be to treat the input type="file" as just a textbox and style it
as such, then treat the browse button as an input type="button" and style it the
way the next found submit button is styled (since otherwise it's impossible to
style it using CSS1, CSS2, or what exists of CSS3).

Actual: I can't even describe it. Will attach testcase and screens.

Build: 2001060104 Win98
*** Bug 90578 has been marked as a duplicate of this bug. ***
C'mon guys, tell me what do I need to fix this bug... it's been to long 
there!!! Needs to be fixed. OK I have Visual Studio 6, will it do? where is the 
code, where is the code? Gee, there should be a link in the page to the code 
that people believe is causing this... I'll send $10 from my paypal account to 
the first person to fix this! Promised!!!
*** Bug 77878 has been marked as a duplicate of this bug. ***
With mozilla Build ID: 20010905, The button created by the INPUT TYPE="FILE"
doesn't receives the CSS configuration: font-size, font-family or height.

Hi gurus, must I file a new bug for this or is this issue covered covered by the
current bug?
I would keep it on this bug. I think fixing this is a matter of changing input
type="file" to an input type="text" and input type="button" with some sort of
internal JS handler. If that happened, all this CSS garbage would be gone.
I just uploaded a new test case

http://bugzilla.mozilla.org/showattachment.cgi?attach_id=49715

Its shows the inconsistency between the length of an input and a file
fields. The file field ignores the style and is significanbly longer
than the input field. Same goes to the Browse button compared to a 
'submit' button.

Tested with 

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.4) Gecko/20010913
*** Bug 101237 has been marked as a duplicate of this bug. ***
*** Bug 101505 has been marked as a duplicate of this bug. ***
Are any of these sufficiently simmilar to warrant
consolidation via duplication or dependancy change?

    bug 33654
    bug 52500
    bug 92980
    bug 103293
    bug 109392

-matt

*** Bug 114823 has been marked as a duplicate of this bug. ***
*** Bug 123142 has been marked as a duplicate of this bug. ***
Priority: P3 → --
Whiteboard: [CSS1-5.5.5][CSS1-5.5.10][CSS1-5.5.22]
With all the great work you guy put into the look and feel of Mozilla, it is a
shame this bug isn't resolved yet. Little visual bugs like this really make
Mozilla look like it isn't finished yet. Could somebody please take another
look at this?
*** Bug 140286 has been marked as a duplicate of this bug. ***
niels wrote:
> Little visual bugs like this really make Mozilla look like it isn't finished
yet. > Could somebody please take another look at this?
 
TRIPLE ACK ! please fix before 1.0

see also bug 118386
This is not a "little visual bug".  It's a fundamental incompatibility between
the CSS box model and the way <input type="file"> controls are expected to look
and act.  The only fix I can think of (short of completely rewriting how <input
type="file"> works) is to disable all application of CSS to this type of control.
> "The only fix I can think of ... is to disable all application of CSS to this
> type of control."

This would be a bad move, as that would render Mozilla incompatible with the CSS
recommendation until the change was undone, leaving us back where we are now.

The best way to do this, at least until someone at W3C decides to figure out a
way to handle browse buttons, is to add Mozilla-specific CSS to style the browse
button, and if that isn't used, style the textbox and the button as if each were
given that style. This would ultimately mean an inset border on the text field
would be drawn as an inset on the button; that could be worked around like it is
in IE6, by flip-flopping the inset to an outset, but we need to leave options
for people who actually *do* want an inset on both the text field and button
(perhaps with that Mozilla CSS). Doing this would solve the dilemma shown on
Neils's testcase, though in that situation the Browse button should have a white
background, like the textbox, not the system color like IE does (background
color applied to the textbox of white should be applied to the button... unless
the background color is styled as transparent, which would leave things as they
are rendered in IE).

It's complicated, but it keeps Mozilla CSS compatible. I'll cut this down to
minor and reword the title just because the original distortion is now gone, as
far as I can see. (If I'm mistaken, change it back. I'll attach a picture of the
latest behavior for me.)
Severity: normal → minor
Summary: [FILE]CSS Styles applied to INPUT TYPE FILE → [FILE] Cannot style INPUT TYPE=FILE button (CSS)
The font style seems to be ignored now.
Summary: [FILE] Cannot style INPUT TYPE=FILE button (CSS) → [FILE] Cannot style INPUT TYPE=FILE completely (CSS)
> as that would render Mozilla incompatible with the CSS recommendation

Not at all.  The CSS recommendation says nothing on this; this is completely
outside its scope.  In fact some members of the CSS Working Group feel that CSS
should not be applied to form controls, period.
Would it be possible to simply treat the browse button as a normal button, and
the text field as a normal text field? Have them seperate entities as far as CSS
is concerned? You wouldn't be able to specify individual classes for each, but
it could at least take whatever style there might be specified for buttons and
input boxes.
input.MyFile#button {
}

input.MyFile#field {
}

The most ideal way to solve this would be to create pseudo-classes for the 
button and the field, so they can be styled independant from each other. But 
that is something the W3C has to solve with their standards. I don't think we 
should create non-standard additions to CSS, despite the fact that it is the 
only way to completely solve this.

Completely ignoring CSS styles, just because their behavoir isn't defined, is 
not really an option either. It's not only ugly, it's a step in the wrong 
direction. It may technically solve the bug, but the real problem still 
remains. To only way to make this predictable and consistant is to emulate IE.

The way I feel is, when the recommendation says "Applies to: all elements," it
should apply to ALL ELEMENTS. Exceptions should only be made in the most extreme
of cases. In my opinion, CSS would be useless if user agents picked and chose
what they want authors to style and not style. The idea of giving the author
total control over a document's appearance should come behind functionality
(like the need for a browse button to connect the file system and the input
type="file" box), but way ahead of programmers' laziness. It would be simple to
just decide not to style this or that, just like it would be simple for your
doctor to decide not to care for a few patients because he doesn't feel like it.
The current behavior is quasi-adequate because at least it styles the textbox
(except that baffling font bug I mentioned), but you know we can do better.

I wouldn't hold my breath waiting for a solution from W3C, simply because CSS
has so many more complex issues to tackle than form controls (as Boris just
said, some of them are aloof to the concept). It's simpler to just apply the
styles, like I said, as if they were individually set on the textbox and button,
except the whole inset/outset business, and handle individual cases with
Mozilla-specific extensions. That would actually put us a step ahead of IE,
since we'd be doing the exact same thing, and still give authors extra control.
Since this is CSS, we can add extensions without worrying about the effect on
other browsers (which will skip the unrecognized code and render the page the
way it would've been without the extensions). I think in this particular case
authors will be more than happy to use the special Mozilla code so they can
style that browse button the way they want.
*** Bug 143774 has been marked as a duplicate of this bug. ***
How about avoiding the issue of what to do with a two-part control by replacing it with some other 
control that doesn't have the separate Browse 
button?

http://www.w3.org/TR/xforms/slice8.html#ui-upload has an attractive example 
design based on a select box.

Hm. That would be a very pleasant solution to this problem... though it would
probably be more difficult than doing what I just described (behaving like IE).
If anyone's up to coding such a thing together, it would be a great solution to
this bug, though it should probably get its own RFE entry for the comment/review
process. I don't want to clutter this bug with a bunch of my ideas for how such
a thing might be done, but for sure it would involve the ACCEPT property (bug
83749) and must accept multiple files (bug 44464). If anyone were to complete
such a project it would need to result in solving those two bugs. If anyone
files a bug for this, link it from here so I can elaborate on how this might work.

Also... are bug 146096 and bug 132565 related to this bug? They might be caused
by the same bad code. Currently, the only remnant effect of this bug AFAIK,
excepting the browse button, is that font styles are ignored, and maybe that
should be split off into its own bug as well. It probably just depends on what
code causes which glitches.
Keywords: testcase
*** Bug 148081 has been marked as a duplicate of this bug. ***
*** Bug 148343 has been marked as a duplicate of this bug. ***
*** Bug 148779 has been marked as a duplicate of this bug. ***
Every solution is good for me, but now I have the problem, and I think that the
best solution is to go the way IE went. So please resolve it before Mozilla 1.1 
*** Bug 149266 has been marked as a duplicate of this bug. ***
I read this bug report with great enthusiasm, but I cannot believe that
nothing has happened in the last 3 months. input[type=file] elements still
look ridiculous on any page that uses CSS to style form elements (1.1 beta).

I can see that the W3C doesn't give explicit instructions about what to do,
but whats wrong with a little interpretation here? This has all been said
before, but what is the point of using CSS to seperate style from content
when User Agents such as Mozilla do whatever the hell they like when it comes
to this element. And don't even mention Select Lists. They are only marginally
better.

As far as any (non-technical, designer, css/html) user is concerned a File 
element is just a Text Box and a Button and they expect it to behave as such. I 
am sure that there are much more interesting/important things for you guys to be 
working on, but things like this are more important to end users.

Finally I apologise for the big moan. I love Mozilla but I fear that things like 
this which are important to end-users but not important to the techies will get 
overlooked.




*** Bug 165536 has been marked as a duplicate of this bug. ***
*** Bug 165723 has been marked as a duplicate of this bug. ***
I've been successfully using pseudo-classes on some form elements, where
necessary. Since Mozilla treats CSS effects on forms differently from IE, then I
wrote some special pseudo-classes for Mozilla. The form elements are built up
using JavaScript. So if the browser sniffer for example identifies anything else
than Netscape>=5 (Mozilla and everything that's derived of it), like IE, it
won't apply the pseudo-class; if it identifies Mozilla, it does. I also have a
noscript option written just in case. And I have long ago noticed how
differently Mozilla applies CSS effects to checkboxes and radio buttons. But I
am not complaining, just wrote how I got over it.
I do something similar, but rather than treating IE as the default and Mozilla
as the special case, I assume a correct implementation of the CSS spec as the
default and make exceptions when necessary for broken implementations. This has
the advantage, at least in theory, of being more or less "future-proof:" as
browsers become more spec-compliant (as most are), you need fewer exceptions. In
practice, this has meant most special cases have applied to IE, especially older
versions.

Of course, this requires that I determine for myself what constitutes a correct
implementation of the CSS spec, which can be non-trivial. ;-)
Blocks: 132565
Perhaps if security is the main issue here, we need to start thinking outside
of the box.  If it is necessary to keep the browse dialog in pristine state so
as to avoid tricking the user, it should be treated more like a dialog instead
of a form input.  Here the input type="file" is used in a tooltip and then
brushed away using visibility toggle.  Upon uploading the file (which is not
activated in this demo) I can assure you it works just fine.

Please note that I never removed the file input from the DOM tree and still
have no way (for security reasons) to modify the file...all I am doing is
putting it to the background when it is no longer needed.
Blocks: 189978
I just wanted to state what has already been written by Stuart Wigley (#42), but
didn't get much attention as it seems. Because the bug mentioned here which is
quite old has not been fixed yet. I know that the most people at mozilla.org
work in their freetime and that such a small issue is not interessting to be
adresed, but then the issue is not hard to fix. Why not just make a file input a
Textinput (which gets skinned) plus a button (which gets skinned, too)!? I'd
like to promote mozilla to our customers, but thats only possible if mozilla
renders at least all the elements used by our web-app correctly which is not the
case for this and bug #193666 which has not been adressed yet neither.
> Why not just make a file input a Textinput (which gets skinned) plus a button
> (which gets skinned, too)!?

How do you think the file control is implemented, eh?  ;)

The problem is that there is no decent way, in CSS, to tell an element something
like "Be colored red unless the color on your parent is set; then have the color
set on your parent" (there is no concept of "set on your parent").  Which is
what we need here, because the button needs to default to button-color, eg,
unless someone styles the file control, in which case it should probably pick up
that color....

*** Bug 201472 has been marked as a duplicate of this bug. ***
This really is a tricky situation because you've essentially got one element
that creates two objects (text and button), and it would be an unfair assumption
that the author wants the text field or button to look like any other text field
or button in the document. And there are certainly going to be people that want
to have the text field be one font and the button be another, for example.

Solution? I think the best way to solve this is to *not* have two distinct
objects. Instead we should have a small box that behaves like a folder window,
in that files, e-mails, or just about anything that can be submitted as a file
can be placed (even dragged) into it. You would get a browse for file dialog if
you click the field. The appearance of the upload control would be similar to
the Download Manager, including the button bar. (It could look like this:
[Browse...|Remove from list] In very small browse windows or in a situation
where the author requests such behavior, the button bar would be removed and the
options would be in a context menu.) As a bonus this would add capability for
multiple file uploads. The colors, borders, and size could be manipulated,
without making the control difficult to recognize. As for the rare case where
value is defined, the browse window would have a file filter that matches the value.
Yeah, but that would break the ability to just type the filename.  I suppose it
could be made to give feedback as to which exact file is being uploaded, if done
right...  How do we make it clear that clicking it will put up a filepicker?
*** Bug 151896 has been marked as a duplicate of this bug. ***
*** Bug 202888 has been marked as a duplicate of this bug. ***
Attached file Alternative on styles — 
An alternative to pseudo-classes is to think of the control as an anonymous
wrapper around both controls.

CSS rules for input[type=text], would only have effect over borders , layout
and size; or could be even ignored, to avoid interferences with other browsers.


Definition of styles for the inner components could be defined just like in the
example. This option has only one advantage over pseudo-classes: it uses
standard selectors, so it is more "standard-compliant".

For example, the "Browse..." button for a file control with class "foo" would
be rendered using the rules:

button { ... }
input[type=file] button { ... }
input[type=file].foo button { ... }

Giving the author much more control over the page than now.

I think this would be one of the cheaper changes to implement.
*** Bug 203608 has been marked as a duplicate of this bug. ***
*** Bug 193885 has been marked as a duplicate of this bug. ***
*** Bug 189978 has been marked as a duplicate of this bug. ***
*** Bug 222859 has been marked as a duplicate of this bug. ***
As per comment 59, you can work around that by simply specifying the form
attribute size.  

Anyone talk to the people who create the specs at the w3c?  This bug has been
around for 3 years and still there is no standard to define it?
As per comment 59, you can work around that by simply specifying the form
attribute size.  

Anyone talk to the people who create the specs at the w3c?  This bug has been
around for 3 years and still there is no standard to define it?
Anyone know if what is programmed at this website is possible? 

http://jscript.dk/2002/8/filestyle.html

It opens the file dialog window in IE when you click on the my file button. 
Notice that the my file button is styled.  
Probably, if they weren't so stupid as to use getElementByID() and then not set
the ID.  The IE hax is matching on name as a fallback.
I didn't program what was at that link but I would think it wouldn't be
difficult to create a function like click() which emulates the file window pop
up.  Then you can create a separate button and text field to set the styles to.
 The only issue I would see is that it would be totally reliant on Javascript
and if someone doesn't have Javascript enabled, then it wouldn't work but in the
mean time until w3c comes up with a solution to this problem, it would be a
great workaround.
*** Bug 230172 has been marked as a duplicate of this bug. ***
well, a long time and a lot of words on this .... but clearly
setting width to an element means setting the width of the 
total of its subcomponents... in the case of input type=file
it means  box+button+margin+padding+border....
clearly not done as the following example demos....
why not fix at least this part and worry about more complex
stylings later... This bug makes many forms look real bad!

<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><title>Style Test</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<style type="text/css">
input {width:120px}
</style>
</head><body>
<h1>Style Test</h1>
<p><input name="x" type="text"  /></p>
<p><input name="x" type="file"  /></p>
<p><input name="x" type="button" /></p>
</body></html>

(In reply to comment #55)
> An alternative to pseudo-classes is to think of the control as an anonymous
> wrapper around both controls.
This is a very good idea, and it is easy to implement. Just change html phaser
so when it sees a <input type="file"> it makes the dom be:
<wrapper>
<textbox>
<button>
</wrapper>
Or somthing like that. How hard can that be to implement anyway? and you get the
ability to style components specily, and you follow css really nicely. (other
browsers may even follow our lead)
> Just change html phaser so when it sees a <input type="file"> it makes the dom
> be

That would break every single page that accesses file inputs via the DOM (and
there are plenty, believe me).  Not an option.
I prefer the way konqueror handles this.
chris: and that would be how?
Konq 3.0.3 simply doesn't apply color styles on the file input to either the
textbox or the button, as far as I can tell.  We could do that, no problem.  ;)
*** Bug 234607 has been marked as a duplicate of this bug. ***
(In reply to Boris Zbarsky in bug 234607 comment 1)
> To clarify, this is a request that page styles _not_ be cut off for this one
> instance of anonymous content, so that if a page sets a style on
> "input[type=text]" that style will apply to the textbox inside the file input.
> 
> This is the one case I can think of where letting pages style anonymous content
> may make some sort of sense, really.

Web pages should not be able to set -moz-binding on any anonymous child of a
file input control, because they could use that to get a JS reference to the
<input type="text"> child (see bug 163768).
Never mind, bz says bug 234607 isn't a dup, so I'm moving my last comment there.
*** Bug 239359 has been marked as a duplicate of this bug. ***
Alias: input[type=file]
Keywords: qawanted
Summary: [FILE] Cannot style INPUT TYPE=FILE completely (CSS) → Cannot style INPUT TYPE=FILE completely
Whiteboard: [CSS1-5.5.5][CSS1-5.5.10][CSS1-5.5.22]
Flags: blocking1.7?
Assignee: rods → nobody
Status: ASSIGNED → NEW
Flags: blocking1.7?
*** Bug 249570 has been marked as a duplicate of this bug. ***
*** Bug 234607 has been marked as a duplicate of this bug. ***
*** Bug 254603 has been marked as a duplicate of this bug. ***
*** Bug 256776 has been marked as a duplicate of this bug. ***
*** Bug 259751 has been marked as a duplicate of this bug. ***
This really is a small problem that should be resolved.

If I can set size="48" on a input[type=file] control and it adjust only the size
of the Text control then when I set style="width: 3in;" then the text control
should resize to (Width - BrowseButtonWidth - ControlSpacing), is that so difficult?

And I realize all the concerns about accessing anonymous content but is that
really a worthwhile concern?  Allow the Text control of to inherit the
properties of Input elements and the Browse button inherit the Button element
properties.

You could even take a step farther then and in CSS a person could do:

<input type="file" class="myfile" />

button.myfile { border: 1px solid black; }
input.myfile { border: 1px solid black; }

Point here is with some creative thinking this annoyance could be resolved and
it wouldn't be that difficult.

Allowing us to set the width of the control in CSS and all it does is resize the
container is utterly pointless.  I really think inheritance could ultimately
satisfy both sides.
*** Bug 264340 has been marked as a duplicate of this bug. ***
*** Bug 270146 has been marked as a duplicate of this bug. ***
*** Bug 273853 has been marked as a duplicate of this bug. ***
*** Bug 274709 has been marked as a duplicate of this bug. ***
*** Bug 275046 has been marked as a duplicate of this bug. ***
How is it that this is still an open issue into 1.0 and beyond?

Because of this, it's currently impossible to apply sizing cross-browser to
<input type=file> elements.

As was said in comment # 82, "(Width - BrowseButtonWidth - ControlSpacing)". 
That is how type=file has always, and *should* be rendered.

The current method of "width + BrowseButtonWidth - Control Spacing" is ridiculous...
*** Bug 285450 has been marked as a duplicate of this bug. ***
*** Bug 288328 has been marked as a duplicate of this bug. ***
Why is this stil not fixed?
As a web designer, I'd liek to say this is really annoying, and to all the
people who found Javascript workarounds, well here's this : I don't think I want
to spend hours trying to make this Browse button look good using complicated
JavaScript. I just want it to work.
At least maybe find some sort of temporary workaround where it renders as a
textbox and a button both using the same class.
*** Bug 288250 has been marked as a duplicate of this bug. ***
*** Bug 290327 has been marked as a duplicate of this bug. ***
as you can see, the width of the textbox is wrong, therefore there is an ugly
coloured patch
the width problem needs to be solved. solution:

textbox width = total width - button width

refer to attachment: "error in width; redvsblue.com" (png) for example of problem
Sorry, but I'm not on your side. I think this bug is no longer something that
should be solved, because it is no longer a bug, but a tradition. I'm watching
this bug now for more than 3 years, and I plan to found a religion based on it.
The church of the "Cannot style INPUT TYPE=FILE completely" guards.

I warn you all, if you send a patch or come up with a solution, I will never
ever  talk to you again.

eT
(In reply to comment #96)
> I'm watching
> this bug now for more than 3 years, and I plan to found a religion based on it.
> The church of the "Cannot style INPUT TYPE=FILE completely" guards.

> eT

Does that make me the Leader of your new Religion or a symbol of worship? :p
Consider me a heretic then!

This is still annoying "behaviour" that is not present in most other browsers.

It'd be nice to see a developer spend 10 or 15 minutes fixing this as it *should
not* be that difficult, unless there is something funny about the way it's
handling this that would make it complicated.
Please do not add useless advocacy comments to bugs. Use the forums to give
feedback.
Those interested in correcting the input="file" width behaviour, should see the
bug 290327. It can be fixed leaving behind bug 52500 discussion what to do with
the rest of input="file" styling (borders, colors, fonts etc.). Just need some
QA confirmation.
Bug 290327 is probably a duplicate of bug 132565, but in my opinion, since it
has a better testcase and an advocacy background in bug 52500, it should be not
marked as such.
Feel free to comment.
Depends on: 290327
The CSS capabilities of the input type="file control still sucks. Why is it
taking so long to fix this? If the W3 standard is lacking we must pressure them
to clarify how ALL attributes of the control should be modified.

People all over the net are frustrated by this, see for instance this guy:
http://www.quirksmode.org/dom/inputfile.html

His solutions are all ugly hacks but afaik this is the best we can today.

Also Mozilla handles with way worse than MSIE6 because Mozilla typically gets
the browser button slightly to the left (15px) of where-you-want-it (ie if you
assign a certain width to the control the button won't appear in the right end
but rather an arbitrary distance from the right end).

I'm VERY VERY frustrated with this bug, I can personally pay atleast $30 to get
it fixed properly (and i'm sure others could cough up some dough too!).
*** Bug 308836 has been marked as a duplicate of this bug. ***
Depends on: 234607
It seems that since this bug was originally reported "some" of the problems have
been fixed.  

Since Firefox/Mozilla seem to follow the spec with all its greatness and
screwups, I assume that none of the problems left are Firefox specific.

I thought that to help clarify the discussion I'd list some things that are
working/not working as of October 2005 (about 5 years after the start of the
thread).

WORKS (or at least "I" am deluded to think it works :) )
- height, font family, font size (if set in CSS for INPUT/BUTTON).
- Input field color (if set in CSS for INPUT).

DOES NOT WORK
- Browse button color is not set by anything.
- width (especially width: 100%;).  What happens is that the "container" for the
 INPUT and Browser objects takes the correct size, but the INPUT field does not
expand to use the available space.  (The "size" tag can be used to specify an
initial number of characters, not even pixels as the standard "appears to be
requiring" - but I might be wrong).

A SIMPLE SUGGESTION

Since the <input type="file"> appears to be a collection of 3 objects (the
container, the "input" field, and the "Browse" button, the most logical solution
would appear to be to:

(a) apply general style clauses as they are applied today, 

(b) apply INPUT style to the input field,

(c) apply BUTTON style to the Browse button.  

(d) If someone wants to set the style for any element, that person could easily
use something like <input id="myFile" type="file"> and define the CSS styles
'#myFile {...}', '#myFile input {...}' and '#myFile button {...}'.


Simple, obvious, and intuitive... unless it is in conflict with the W3C spec.  

If this is an acceptable solution, please consider implementing it in the next
patch, and possibly recommend it to the W3C.  I expect that Microsoft will try
to object to a W3C change since their browser work fairly well in quirks mode
and it gives them a small competitive advantage, but it might be worth the fight.

In the meantime, I guess we have to continue doing hacks :P
Can we PLEASE PLEASE PLEASE fix the width problem.

i quote:
  - width (especially width: 100%;).  What happens is that the "container" for the
    INPUT and Browser objects takes the correct size, but the INPUT field does not
    expand to use the available space.  (The "size" tag can be used to specify an
    initial number of characters, not even pixels as the standard "appears to be
    requiring" - but I might be wrong).

I see this problem from a web developers point of view, and it makes a page look
screwy when theres a big block of white space just haning around just because
you wanted to make all your input elements the same size because that makes it
look GOOD!

Thankyou.
A quick band-aid to this problem would be to enable the .click() javascript
function for <input type="file">.  

Then we could make the whole stupid field hidden and use an <input type="text">
plus an <button ... onClick="... click()"> to do the real work. These 2 fields
are normal fields and therefore can be fully styled. 

This band-aid solution is already available in other browsers, even though it is
not really a W3C endorsed one.  
(In reply to comment #104)
> Can we PLEASE PLEASE PLEASE fix the width problem.

Since there is nobody assigned to this 5-year-old issue and people like us look
here for solutions, here is a band-aid until someone resolves the issue.  It is
a hack, it is ugly, and it uses tables in addition to CSS (shivers).  But it
works and allows for 100% and styling of the button and input field.  

#updPhoto {
  position:           relative;
  width:            100%;
}
#updPhoto table {
  border-collapse:    collapse;
}
#updPhoto td {
  padding:            0px;
}
#updPhotoTxt {
  z-index:           33;
  width:            100%;
}
#updPhotoBtn {
  z-index:           31;
}
#updPhotoFile {
  z-index:           32;
  position:           absolute;
  top:                0;
  right:              0;
  height:            20px;
  align:              right;
  -moz-opacity:       0;
  filter:             alpha(opacity: 0);
  opacity:            0;
}
...
<div id="updPhoto">
  <table><tr>
    <td><input  id="updPhotoTxt" name="updPhotoTxt" type="text" value="" 
readonly="true" disabled="true" /></td>
    <td>&nbsp;<button id="updPhotoBtn" name="updPhotoBtn" 
type="button">Browse</button></td>
  </tr></table>
  <input type="file" id="updPhotoFile" name="updPhotoFile" value="" size="1"
onchange="document.getElementById('updPhotoTxt').value=this.value"/>
</div>


For testing I recommend commenting the 3 opacity lines in the style... and
adjust the code as needed.


also on ie you may use a click(); method to open the browse dialog, you cannot with firefox example code is

<input type='file' id='file_input'>
<input type='button' onclick='document.getElementById("file_input").click();'>

works in ie but not firefox, would be very usefull to have in next update
Sean: that's bug 36619.
Can someone give an overview about what the programming problems are for fixing this bug in any of the suggested ways?

The rendering of this control type is not in the specifications (HTML nor CSS). This means that, AFAICS, the way to apply styles to it will always be browser specific. We will never get an answer from the HTML specification, simply because the control description has intentionally been left open.

It is not even necessary to behave like any other browser. It would be enough to be able to specify the styles withouth hacks, in such a way that will not clash with other browsers.

Why not simply define three pseudo-elements (for example ":-moz-file-container", ":-moz-file-textarea" and ":-moz-file-button") and make the render engine honour the styles defined in them?

I am tired of this endless discussion. Now, I simply would like to understand which are the technical difficulties.


*** Bug 323648 has been marked as a duplicate of this bug. ***
i'm just going to guess that https://bugzilla.mozilla.org/show_bug.cgi?id=258875 will be fixed before this.
*** Bug 343480 has been marked as a duplicate of this bug. ***
*** Bug 346726 has been marked as a duplicate of this bug. ***
Attached image suggested behaviour — 
<input type="file" style="background:#000;color:#fff;font:10pt monospace;border:1px solid #fff" size="32" />

As I understand it, that CSS should set the background of both the text box and the button to #000, text colour of both the text box and the button to #fff, the font of both to 10pt monospace, and the border of both to 1px solid #fff. (See attached image.) The size given should cover the full width of the <input>, including the "Browse..." button.
Any update about this very old bug ?
I too am noticing this bug.  V. 2.0.0.6/Linux
I noticed that there is not report of not being able to style background image of a file input. So I attached a screen shot comparing it with a textbox. I can't think of a major security problem and people are already generating the same effects with opacity effects.
QA Contact: ian → layout.form-controls
The behavior of styling file inputs in FF3.0 is changed compared to FF2.0. File input elements can't be styled for background color now. See the attached image. Is this a regression?
and for comparison here is how Safari (v3.0.4) render the file input styling.
Depends on: 419973
The solution to this seems simple to me and is much as is outlined in comment #103.

The text box obeys styles applied to input{}, the browse button styles applied to button{}, the box containing them obeys styles applied to input{}.

When the page element is:

<input type="file" id="foo" />

To style the containing box only you say input[type=file]{}, to style the text box you say input[type=text]#foo{}, to style the button you say input[type=button]#foo{}

This is valid CSS and as long as IDs are unique on the page allows you to target *just* the file input and browse buttons without additional hackery. It will even degrade somewhat nicely when other browsers are involved.

The only funky part of this is that you effectively have one ID for two elements (or three, really). You have an element which (sort of) is type=button and type=text and type=file at the same time. That's a kind of funky I'm guessing could be handled.
just for reference
I can confirm this bug is still in the final release of FF3.
Following on from comment #125 I think it would make more sense if, in the DOM, the file input were treated as *containing* both a text input and a button input. So when browsing in Firebug it would look like:

<input type="file" id="fileInput">
    <input type="text"></input>
    <button text="Browse..."></button>
</input>

This could be implemented along the lines of how <tbody> and <thead> appear within tables...

So if we want to style the individual elements we can use these rules:

#fileInput {
    /* Styles for both sub-elements to inherit */
}

#fileInput input[type=text] {
    /* Style the text box */
}

#fileInput button {
    /* Style the button */
}

This could have the advantage of being able to manipulate the button text in Javascript (although maybe undesirable from a security point of view, being able to manipulate the style in the first place could equally be considered a security threat and if someone really wants to mask the behaviour/appearance of the browse button to that extent they can still acheive so by far more complex methods...)

I think a <button> element would make more sense since Browse does *not* have a submit behavior.



Yeah, but that's not how <input type="file"> is defined in the (X)HTML spec, the W3C DOM, *or* the CSS spec. (X)HTML treats it as a single element; W3C DOM treats it as a single element. You can't just arbitrarily decide that you're going to ignore the specs and treat it as two separate elements. It's *not* two separate elements.

The problem is with the standards; there's simply no Right Way to control styling of <input type="file"> under the current specs. Any solution in the browser will necessarily be a proprietary kludge. Remember Netscape vs. IE4? We don't want to go back to those days :)


However it has been officially defined, it is clearly a composite element consisting of two sub-elements. In my experience the W3C specs are usually pretty vague on the actual implementation of certain edge cases, and a lot of "undefined" factors are left open to interpretation. This is why web standards are still in such a mess.

Perhaps you could provide a link to the relevant part of the spec to back up your claim. I just tried to find it, and couldn't see anything specifically relating to  <input type="file"> in W3C's XHTML spec. I think it is just inherited from HTML4, which is itself a legacy from "those days". I couldn't see anything in the HTML4 specs specifically stating that it was a single element; just that it was a control for selecting files. ...So the composition of that control is completely open to interpretation.

Really we have to blame the specs, for not clarifying this in more detail. But what can we do about it? Let's look at what the control is: it's a composite control consisting of an input box and a button, which is hard-wired to a particular dialog.

I don't agree that "Any solution in the
browser will necessarily be a proprietary kludge". I think that any solution in the browser is a necessary (and valid) implementation of a vague spec.

Any web designer who actually needs that level of control of actually styling the file input, is more than capable of applying different proprietary styles in different browsers... far easier than any current Javascript hack to "skin" the control!

> Perhaps you could provide a link to the relevant part of the spec to back up
> your claim. I just tried to find it, and couldn't see anything specifically
> relating to  <input type="file"> in W3C's XHTML spec.
The tags and behaviors for the XHTML namespace are indeed inherited from HTML 4.01.  I don't see anywhere in the standard that specifically states this, but it is implied through the specification and stated in the DTD (http://www.w3.org/TR/xhtml1/dtds.html#a_dtd_XHTML-1.0-Strict).

> I couldn't see anything in the HTML4 specs specifically stating that it was
> a single element; just that it was a control for selecting files
Correct.  However, note that the file input control is a case of the input element, just like the text input control or hidden control.  The file input is a single element by definition.

Therefore, I don't aggre with the opinion that the specs are the problem.  They are clear about what the element must do and what styles would apply to the element.  The part they are not clear on the design of the element itself.

I personally believe that the current combination text & button style file upload element is the problem.  This implemen makes it difficult to properly apply the standards.  In my opinion, by disabling direct input of file names in Firefox 3, we rendered the text input portion completely pointless.  I see no reason for Firefox to continue implementing a file input design which has been the cause of numerous problems (this bug, bug 374011, bug 443439, the confusing nature of the Firefox 3 upload field, etc.).

My suggestion would be a redesign of the file input element.  One idea worth investigation would be a Safari-style element consisting of a single button that displays an "Upload file..." text when empty or some kind of obvious file indicator (file name/path) when a file is selected.  Pretty much exactly what was described 5 years ago in comment #51.
(In reply to comment #132)

> I personally believe that the current combination text & button style file
> upload element is the problem.  This implemen makes it difficult to properly
> apply the standards.  In my opinion, by disabling direct input of file names in
> Firefox 3, we rendered the text input portion completely pointless.  I see no

I guess this is a regression. The browse dialogs on major platforms are slow, confusing, and hard to use. The option to just paste in a filename if you have it at hand speeds up and simplifies the process quite a bit.

> reason for Firefox to continue implementing a file input design which has been
> the cause of numerous problems (this bug, bug 374011, bug 443439, the confusing
> nature of the Firefox 3 upload field, etc.).

This design is similar to what is used in platform dialogs where a text field and a button is typically used to input a file. This is what users know and expect from other applications on their platform, and anything that deviates from this expectation should be well thought out, and utterly self-explaining and obvious.

> 
> My suggestion would be a redesign of the file input element.  One idea worth
> investigation would be a Safari-style element consisting of a single button

What Safari does is replacing the text field with a label. This is even more problematic than what we have now. It deviates from the "standard" way of doing things, it makes it less obvious that the text is somehow part of an input or attached to the button, the element is still composite, and the label part is even no longer an input so it's even harder to apply styles consistently to it.

> that displays an "Upload file..." text when empty or some kind of obvious file
> indicator (file name/path) when a file is selected.  Pretty much exactly what
> was described 5 years ago in comment #51.

An inline file browser would be problematic because it requires lots of page space and system resources while people assume file inputs are small and light, and place them just in case even on forms that are seldom used to actually upload anything.

A simple but obscure control that somehow magically accepts DnD (which is very buggy and poorly supported on X11) or opens a browse dialog when somebody frobs it in the right way is not what I consider self-explaining and obvious.
> An inline file browser would be problematic because it requires lots of page
> space and system resources while people assume file inputs are small and light,
> and place them just in case even on forms that are seldom used to actually
> upload anything.

I guess I didn't read the description in comment #51 closely enough.  I would definitely not be in favor of having an in-browser file selector.  Also, I didn't have a copy of Safari in front of me when I filed that comment since I run Linux, so I guess I assumed its behavior from what I had previously heard.

> This is even more problematic than what we have now. It deviates from the
> "standard" way of doing things

If we want to talk about deviation from the standard way of doing things, the new behavior is definitely a violation of that.  The Linux theme is especially bad because the disabled styling of the text box is barely any different from the default styling.  But that's a different bug.

What I intended to describe was placing everything directly on the button itself.  No messing around with a pointless text input element plus it's a simple design.  Users are used to just going and pushing buttons anyways, and if you place Upload File on there as default text it's even more self explanatory.  Then when a file is selected the name will display on the button itself, and the user just has to push again to change it.
(In reply to comment #132)
> Therefore, I don't aggre with the opinion that the specs are the problem.  They
> are clear about what the element must do and what styles would apply to the
> element.  The part they are not clear on the design of the element itself.

How can it be clear what styles should apply to an element (and *how* they will apply), if the design of the element is not specified?

I think comment #109 hit it on the head; that since this implementation is "undefined" in the specifications, then a browser-specific solution is *expected*. The idea of proprietary mozilla pseudo-elements is probably the least ugly implementation, won't break any other browsers, and opens up the functionality for those number of cases where styling of the file input is required. And it really is a minority of situations where this is required; unfortunately if you currently encounter such a situation then it's a *real* pain.

(In reply to comment #134)
> What I intended to describe was placing everything directly on the button
> itself.  No messing around with a pointless text input element plus it's a
> simple design.  Users are used to just going and pushing buttons anyways, and
> if you place Upload File on there as default text it's even more self
> explanatory.  Then when a file is selected the name will display on the button
> itself, and the user just has to push again to change it.

The problem I can see with this, is that the size of the button will change
depending on the length of the file name. For pages where "size matters", this
will break the layout fantastically.

I've been thinking about an idea for an entirely new interface for file
uploads:

 - Implement a new sidebar file explorer, to replace the current modal dialog.
Each <input type="file"> would be internally linked to an "upload slot",
displayed at the top of the sidebar - so files can be dragged and dropped from
the browser to the slots. (Making it far easier for things like uploading
multiple files from an image folder, since your explorer session now stays on
the screen). The <input type="file"> itself would then just be rendered as a
single button, which would pop open the new sidebar when clicked. It would then
be treated just like any other button when it came to styling. This would fix
all issues of security and styling relating to uploads, since the uploader is
now part of the browser UI rather than being a page element. When a file is
chosen, the value property of the linked input is updated as normal.

 - The browser then displays a *progress bar* for each file when the form is
posting. Why has this never been implemented? When uploading anything more than
500k or so it's a case of holding your breath and praying... I've spent weeks
implementing an upload progress bar with a mix of client and server
technologies, and quite frankly it's one of the hardest tasks I've ever
attempted, for something that should already be in the UI! (I realise that's
probably a separate ticket...)

Does this sound like a good "new" solution? ...I hope I'm clearly describing
what I'm visualising!
(In reply to comment #136)
> (In reply to comment #134)
> > What I intended to describe was placing everything directly on the button
> > itself.  No messing around with a pointless text input element plus it's a
> > simple design.  Users are used to just going and pushing buttons anyways, and
> > if you place Upload File on there as default text it's even more self
> > explanatory.  Then when a file is selected the name will display on the button
> > itself, and the user just has to push again to change it.
> 
> The problem I can see with this, is that the size of the button will change
> depending on the length of the file name. For pages where "size matters", this
> will break the layout fantastically.

Also you cannot tell easily if you are uploading a file "Upload a file" or there is no file selected, and there is no way how to remove the filename ...

Changing the text on a button is very unusual in current UIs so it would be probably very counter-intuitive for most users.

Of course, you could possibly keep the button pressed when there is a file selected, at least on platforms that have some notion of permanently pressed buttons. This would also make it look much like a text field in many cases.

> 
> I've been thinking about an idea for an entirely new interface for file
> uploads:
> 
>  - Implement a new sidebar file explorer, to replace the current modal dialog.
> Each <input type="file"> would be internally linked to an "upload slot",
> displayed at the top of the sidebar - so files can be dragged and dropped from
> the browser to the slots. (Making it far easier for things like uploading
> multiple files from an image folder, since your explorer session now stays on
> the screen). The <input type="file"> itself would then just be rendered as a
> single button, which would pop open the new sidebar when clicked. It would then
> be treated just like any other button when it came to styling. This would fix
> all issues of security and styling relating to uploads, since the uploader is
> now part of the browser UI rather than being a page element. When a file is
> chosen, the value property of the linked input is updated as normal.

However, this does not make it apparent from the form itself if anything is uploaded and separates the actual value from the control which will make it very hard to find the value. This will be even worse once the sidebar is displayed and pressing the button does not trigger any obvious action.

Also making a sidebar does not solve the resize problem. On some sites not only control size matters but also the window size matters (or the whole page size matters), and when you display the sidebar you have to take the room for it from somewhere.

> 
>  - The browser then displays a *progress bar* for each file when the form is
> posting. Why has this never been implemented? When uploading anything more than
> 500k or so it's a case of holding your breath and praying... I've spent weeks
> implementing an upload progress bar with a mix of client and server
> technologies, and quite frankly it's one of the hardest tasks I've ever
> attempted, for something that should already be in the UI! (I realise that's
> probably a separate ticket...)
> 
> Does this sound like a good "new" solution? ...I hope I'm clearly describing
> what I'm visualising!
> 

This would be a nice extension (similar to download sidebar or download toolbar) but probably not something the majority of users would easily understand and use.
(In reply to comment #137)
> However, this does not make it apparent from the form itself if anything is
> uploaded and separates the actual value from the control which will make it
> very hard to find the value. This will be even worse once the sidebar is
> displayed and pressing the button does not trigger any obvious action.

The input.value property of the original control would be populated as soon as a file is selected in the upload slot (and associated Javascript events fired, in case we want to do an AJAXish instant upload).

However you are right, there is still no indicator on the page that this input has a file; so we are back to an unstylable composite. [sigh]

> Also making a sidebar does not solve the resize problem. On some sites not only
> control size matters but also the window size matters (or the whole page size
> matters), and when you display the sidebar you have to take the room for it
> from somewhere.

True, but this is a problem in any scenario. Different people have different sized monitors. Pages *should* be designed so they can fit different widths. A sidebar opening up is far less of a problem than an element changing size unexpectedly, and the sidebar can be closed when you're finished with it...

With the current modal dialog, the entire page is frozen while you're browsing - at least this solution would leave the user some control. The sidebar could also have a "floating" mode where it would not affect page layout.

Redundant discussion, really. The sidebar could be a great new feature but as you've illustrated it doesn't fix our original problem...

Typical Gecko progress: 138 comments, IE8B2 now partially supports CSS styling on file input elements, 73 votes...how difficult is it to attach styling to an element? As a web designer I'm going to actually have to "hack" for Gecko in 2009 and not hack for IE.

This is *NOT* a difficult issue people!

border: #f0f solid 1px;

Obviously both the text field and the button receive a black single pixel solid border.

background-color: #fff;

Obviously both the text field and the button receive a white background color.

I think the *ONLY* thing that might be remotely debatable here is the spacing between the text and button fields. I think this should be inherited by the border width as it does not count as margin, padding, or outline. It's logical to conclude that a 1, 2, 3, or 4px thick border would look appropriate with the same spacing between the two sub-fields. Worst case scenario a proprietary -moz property could be created to define this.

Of course the worst case scenario could be we continue to wait forever for the important stuff to get worked on.
The net result is that most sane developers turn to additional components to implement a decent-looking and functional file upload (i.e. also displaying a proper progress bar which, to be honest, should have been a part of the browser since day 0).

There have been great Flash uploaders around for a while and now Silverlight 2 beta 2 also provides suitable functionality. The down-side is you'll still need an appopriate server-side handler.

Other advantages of such plug-in components are:

- You can filter the types of file allowed (yes, a "Files of this type" drop-down box as seen in Open File dialogs since GEM)

- You can multi-select files (my gosh!)

It doesn't need to take the browsers this long to catch up, surely?
Hi John, I always enjoy reading your comments on the IE Blog, and I must admit it is odd to see the rant on Mozilla, not IE.

I would disagree with the "this is not difficult" statement.  I think that this is actually quite difficult because the form control in question is actually made up of 2 controls, effectively an input type="text" and an input type="button"... where in FF3, the input is readonly, with an onclick handler that calls .click() on the button, and the value of the button is readonly too.

I think I would rather see the input apply CSS styles, "as if" it contained this structure.

<input type="file">
  <input type="text"/><input type="button" value="Browse..."/>
</input>

thus CSS would allow styling like:

/*CSS styles for pseudo file input*/

/* The input wrapper */
input[type=file] {
  border: 1px dotted #ccc;
  border-radius: 3px;
}

/* The text box part */
input[type=file] > input[type=text]{
  border: 1px solid #0000ff;
  min-width: 150px;
  max-width: 300px;
  overflow: auto;
}

/* The button part */
input[type=file] > input[type=button]{
  border: 2px outset #00cc00;
  background: #cccccc url('img/paperclip.png') no-repeat middle left;
  padding-left: 20px;
}


I realize that the above is a bit "out there", but I think that trying to apply styles for 1 "physical" element to 2..3 "virtual" elements just won't work.  This is why so many developers have opted to "enhance" their upload process by using stuff like the SWFUpload code.  It may require flash, but the user experience is just so much better. (Note: I don't have any beef with how Mozilla is handling this, I think the HTML/CSS specs are not quite flexible enough to handle this scenario appropriately.
Steve, the problem with that CSS is that the recommendation doesn't enforce browsers to use a text input plus a button (iirc, for one, it's different on Safari), meaning that you're going to get even more inconsistencies. Not that I agree with John's rant either. I'm not trying to propose a solution here, because I don't think there is one, and trying to meet in the middle between OS integration and semantic code will most likely leave everyone disappointed--which is probably why this is still an issue.
Can we please at least address the width problem.

See the following attachments:
https://bugzilla.mozilla.org/attachment.cgi?id=321238
https://bugzilla.mozilla.org/attachment.cgi?id=321239

It cannot be very hard to fix the width bug. I would think that the button would always be the same size and the text box would change size.

I have attached how Gecko should render the situation shown in the attachments above.
Attachment #336649 - Attachment description: How the widths of the fields should look → How the widths of the fields should look. Mockup made in The Gimp.
Honestly, the right solution here will most likely involve moving to a more Safari-like presentation of the control, plus some serious thinking about how the styling should work.  What would help most in designing something like that is a summary document that describes the various styling issues people currently have with <input type="file">, so that whoever is doing the designing doesn't have to read this entire bug plus all the duplicates and dependencies and try to extract that information from amongst all the other things they contain.

Steve, for what it's worth what you describe is exactly what Gecko does from the point of view of the UA and user sheets.  Author sheets can't see the anonymous text input and button, because that's what the CSS specs say to do... and because we wouldn't want authors depending on the internal details of how we implement the file input, honestly.
Josh, implementing what you suggest doesn't sound all that easy, actually, but it might be doable.  Would you be willing to file a separate bug with a clear description of just that problem and your suggested behavior, as well as a description of how you expect the input to behave when the specified width is smaller than the button width?  Assign the bug to me and mark it blocking this one, and I'll see what I can do.  Make sure to mention in your comment that it is NOT a duplicate of this "make-it-all-work-somehow" bug, but a specific bug on a specific issue with a specific proposed solution?
Comment #145
> Josh, implementing what you suggest doesn't sound all that easy, actually, but
> it might be doable.  Would you be willing to file a separate bug with a clear
> description of just that problem and your suggested behavior, as well as a
> description of how you expect the input to behave when the specified width is
> smaller than the button width?  Assign the bug to me and mark it blocking this
> one, and I'll see what I can do.  Make sure to mention in your comment that it
> is NOT a duplicate of this "make-it-all-work-somehow" bug, but a specific bug
> on a specific issue with a specific proposed solution?

Isn't that already bug #290327?
(In reply to comment #144)
> Honestly, the right solution here will most likely involve moving to a more
> Safari-like presentation of the control, plus some serious thinking about how
> the styling should work.

At which level, Gecko or HTML? If HTML dictated the appearance of the component, that would probably simplify things. If only there were a proposed appearance we could all agree on.
> Isn't that already bug #290327?

Ah, indeed.  Care to spec out how small widths will work?  That's the missing piece there.

> At which level, Gecko or HTML? 

Gecko.
Depends on: 453535
(In reply to comment #145)
> Josh, implementing what you suggest doesn't sound all that easy, actually, but
> it might be doable.  Would you be willing to file a separate bug with a clear
> description of just that problem and your suggested behavior, as well as a
> description of how you expect the input to behave when the specified width is
> smaller than the button width?  Assign the bug to me and mark it blocking this
> one, and I'll see what I can do.  Make sure to mention in your comment that it
> is NOT a duplicate of this "make-it-all-work-somehow" bug, but a specific bug
> on a specific issue with a specific proposed solution?

Boris, I have created the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=453535

Not sure how to assign it to you though. I was going to dive into the source
and try to fix it myself but then again the source as I understand is huge...
A discussion has been started on the dev-tech-layout list regarding new requirements for input type="file".  You guys might be interested by it.
Depends on: 431524
Blocks: 253690
HTML5 does not allow the attribute "size" in <input type="file">. So how do we set a width, when styling is not possible? I like to produce valid HTML5.
I've done a quick walk through all major browsers, and Firefox is the only one where these input elements can't be styled. Even in IE6 Nico Rohrbach's test-site works! This bug is still present in FF3.7a3, so this bug needs to be fixed in the latest Gecko engine.
A couple months ago I decided to try my hand at creating some Web pages and at that time got the latest versions of Firefox, Internet Explorer and Chrome.  

At one point I did some playing with the HTML "input" element, where type='file'.  On a web page this displays a blank datafield and button that causes a pop-up window, in which you can access the computer file-system to select a file.  After selecting a file, the datafield will contain the path/filename.

I used a "style" setting to try to change the default font for this HTML element, and it didn't work for FireFox.  When I tried out my code on Chrome, both the text of the path/filename and the text of the button were changed to the new font.  When I tried Internet Explorer, the text of the button was not changed, but the text of the path/filename was changed to the new font.

I wonder what the Standard Behavior is supposed to be?  I'm pretty sure at least the display of the path/filename text should be alterable.
PS: The only way to change the size of an input type=file in Firefox, is by setting the 'size' attribute:

<input type="file" size="25" />

It would be better if you could style it via CSS, like in all the other browsers.
(In reply to Rick van de Westelaken from comment #160)
> PS: The only way to change the size of an input type=file in Firefox, is by
> setting the 'size' attribute

The 'size' attribute should not be used to set the width of (In reply to Rick van de Westelaken from comment #160)
> PS: The only way to change the size of an input type=file in Firefox, is by
> setting the 'size' attribute:
> 
> <input type="file" size="25" />
> 
> It would be better if you could style it via CSS, like in all the other
> browsers.

I agree. The 'size' attribute should not be used to set the width of the component which should be done via CSS.

Proposed fix:

File forms.css (resource://gre-resources/forms.css)
[omni.jar/chrome/toolkit/res/forms.css]

Add to input[type="file"] > input[type="text"]
  width: -moz-calc(100% - 7em);

Add to input[type="file"] > input[type="button"]
  width: 7em;

Here are some screenshots showing this fix:
http://img40.imageshack.us/img40/576/newif1.png
http://img148.imageshack.us/img148/5669/newif2.png
http://img718.imageshack.us/img718/3391/newif3.png

Code:
http://img199.imageshack.us/img199/985/newifcode.png
Almost 12 years past... I understand about style likes "border" or "color", but why firefox still ignore "width" style? Currently it is only one browser, which ignore "width" style and use only "size" attribute...

Can you fix at least "width"?

thank you.
Yes, please fix at least 'width' - that just annoying.
In fact, the width is often the recurrent problem before everything else.
Would be really nice to be able to set the width of the input manually by css.
Remember to vote on this issue to get it prioritized.
Blocks: 234607, 290327
No longer depends on: 234607, 290327
Blocks: 845454, 855736, 857409
Summary: Cannot style INPUT TYPE=FILE completely → Make regular CSS properties apply on <input type='file'>
Target Milestone: Future → ---
Attached patch Patch — — Splinter Review 
It should allow styling <input type=file> as much as any other browser without using pseudo-elements.
Assignee: nobody → mounir
Status: NEW → ASSIGNED
Attachment #732865 - Flags: review?(bzbarsky)
No longer blocks: 857409
Comment on attachment 732865 [details] [diff] [review]
Patch

>+  padding: 0px 0px 0px 0px;

"padding: 0;"

Have you looked into why the "clip height only" code is there?

Furthermore, why do we no longer need the event hackery?
Attachment #732865 - Flags: review?(bzbarsky)
(In reply to Boris Zbarsky (:bz) from comment #169)
> Comment on attachment 732865 [details] [diff] [review]
> Patch
> 
> >+  padding: 0px 0px 0px 0px;
> 
> "padding: 0;"

Oups, this is the rest of some tests.

> Have you looked into why the "clip height only" code is there?

The reason was because back in the days, we wanted to make sure the file picker UI can't be hidden. This is something we no longer care about.

> Furthermore, why do we no longer need the event hackery?

I just don't see why this is there. Clicks don't seem to work when the element is disabled and tests are passing without it. If you can point me a case were that hack is needed, I would gladly re-introduce it.
Attachment #732865 - Flags: review?(bzbarsky)
Comment on attachment 732865 [details] [diff] [review]
Patch

Hmm.  So the original commit for the display item thing had this bit:

 590 // REVIEW: I'm not sure why we do this, but that's what nsFileControlFrame::
 591 // GetFrameForPoint was doing

I guess in practice it doesn't matter because we don't hand out references to the NAC to anyone anyway.

r=me
Attachment #732865 - Flags: review?(bzbarsky) → review+
Blocks: 859714
No longer blocks: 859714
Blocks: 859714
Blocks: 864478
Finally solved the tests issues...

https://hg.mozilla.org/integration/mozilla-inbound/rev/132a424d1a28

Should be tracking firefox 22 and 23, given that this bug should solve bug 859714 and bug 864478.
tracking-firefox22: --- → ?
tracking-firefox23: --- → ?
Flags: in-testsuite+
Target Milestone: --- → mozilla24
https://hg.mozilla.org/mozilla-central/rev/132a424d1a28
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Comment on attachment 732865 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): caused by the new <input type='file'> style.
User impact if declined: this is fixing a couple of regressions like bug 859714 and bug 864478.
Testing completed (on m-c, etc.): automated tests
Risk to taking this patch (and alternatives if risky): low risk but backing out the changes made to the <input type='file'> style would be a less risky alternative if it doesn't involve merging.
String or IDL/UUID changes made by this patch: none
Attachment #732865 - Flags: approval-mozilla-beta?
Attachment #732865 - Flags: approval-mozilla-aurora?
Keywords: verifyme
Depends on: 874600
Comment on attachment 732865 [details] [diff] [review]
Patch

We can take this low risk forward fix, and it's early enough in Beta to get it landed & tested prior to release.
Attachment #732865 - Flags: approval-mozilla-beta?
Attachment #732865 - Flags: approval-mozilla-beta+
Attachment #732865 - Flags: approval-mozilla-aurora?
Attachment #732865 - Flags: approval-mozilla-aurora+
(In reply to Ryan VanderMeulen [:RyanVM][Out May 23-27] from comment #176)
> https://hg.mozilla.org/releases/mozilla-aurora/rev/b31b08960f75
> 
> This has lots of conflicts on beta.

Argh, bug 857536 didn't went to Beta. We should uplift this one too.
Depends on: 857536
Tested on Firefox 22 beta 3. The following test cases work as expected:
- Test case - file input with border, padding, margin
- INPUT TYPE="file" testcase (with accept and style)
- Alternative method for styling input type=file
- css width property — bright, easy-to-understand testcase

The following test cases still reproduce their initial issue:
- Inconsistency between 'input' and 'file' field sizes
- Alternative on styles
(In reply to Ioana Budnar, QA [:ioana] from comment #179)
> The following test cases still reproduce their initial issue:
> - Inconsistency between 'input' and 'file' field sizes
> - Alternative on styles

Should I file follow up bugs for these two cases or is the current behavior what you intend to keep by design?

Is there anything else you would like me to test for this bug fix?
Flags: needinfo?(mounir)
(In reply to Ioana Budnar, QA [:ioana] from comment #180)
> (In reply to Ioana Budnar, QA [:ioana] from comment #179)
> > The following test cases still reproduce their initial issue:
> > - Inconsistency between 'input' and 'file' field sizes
> > - Alternative on styles
> 
> Should I file follow up bugs for these two cases or is the current behavior
> what you intend to keep by design?

The size attribute shouldn't apply on <input type='file'>. The fact that it was was a bug in Gecko. This test is then deprecated.

Regarding the "alternative on styles", it is a proposal and the behaviour of the test case is consistent between browsers so I do not think there is a bug here.

> Is there anything else you would like me to test for this bug fix?

I think we are good. Thanks :)
Flags: needinfo?(mounir)
Ioana, can you please test this with Firefox 23 as well?
Keywords: qawanted
Verified as fixed on:
Mozilla/5.0 (X11; Linux i686; rv:23.0) Gecko/20130620 Firefox/23.0
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20130620 Firefox/23.0
status-firefox23: fixed → verified
QA Contact: ioana.budnar
Will this allow repositioning of the BROWSE button to the right hand side (and outside of the text box) as it was before v22 ?
Testing on Firefox 23, 24, and 25 Nightly I haven't been able to style the input[type=button] at all. It's nice that we finally have SOME ability to style though I'd really like to change the background-color, font, width, etc of the file input element's button. Is that currently possible? I've tried this based on what other people have posted here...

<input id="example" name="example" type="file" />

input[type='button']#example
{
 border: #0f0 solid 1px;
 float: right;
 width: 500px;
}

#example[type="button"]
{
 border: #0f0 solid 1px;
 color: #fff;
 width: 500px;
}
There is no <input type="button"> in the DOM.  And pages can't style random anonymous content (which btw is not an <input type="button"> either in this case).
It would be great if discussing the anonymous content styling was done in bug 234607 instead of here.
Verified as in my above comments on Firefox 24:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0
Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Firefox/24.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Firefox/24.0
Status: RESOLVED → VERIFIED
status-firefox24: fixed → verified
Keywords: verifyme
I hate this design, as do many other users. Mozilla has become a tone-deaf clone, the Moammar Gaddafi of the browser wars. It's time for it to move aside and make way for a new layout alternative.
See Also: → 1460186
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: