Closed
Bug 52500
(input[type=file])
Opened 24 years ago
Closed 12 years ago
Make regular CSS properties apply on <input type='file'>
Categories
(Core :: Layout: Form Controls, defect)
Core
Layout: Form Controls
Tracking
()
VERIFIED
FIXED
mozilla24
People
(Reporter: thorne, Assigned: mounir)
References
(Blocks 1 open bug)
Details
(4 keywords)
Attachments
(20 files)
279 bytes,
text/html
|
Details | |
193.35 KB,
image/jpeg
|
Details | |
20.11 KB,
image/jpeg
|
Details | |
1.18 KB,
text/html
|
Details | |
2.35 KB,
image/png
|
Details | |
381 bytes,
text/html
|
Details | |
38.88 KB,
image/gif
|
Details | |
11.67 KB,
image/png
|
Details | |
12.08 KB,
text/html
|
Details | |
2.44 KB,
text/html
|
Details | |
87 bytes,
text/html
|
Details | |
5.56 KB,
image/png
|
Details | |
3.69 KB,
image/png
|
Details | |
15.75 KB,
image/png
|
Details | |
29.01 KB,
image/png
|
Details | |
25.56 KB,
image/png
|
Details | |
481 bytes,
text/html
|
Details | |
41.34 KB,
image/png
|
Details | |
40.79 KB,
image/png
|
Details | |
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
Comment 1•24 years ago
|
||
mthorne@nf.sympatico.ca - could you attach a screenshot and/or a testcase please?
Comment 2•24 years ago
|
||
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
Comment 3•24 years ago
|
||
Updated•24 years ago
|
Reporter | ||
Comment 4•24 years ago
|
||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Summary: CSS Styles applied to INPUT TYPE FILE → [FILE]CSS Styles applied to INPUT TYPE FILE
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
Comment 10•24 years ago
|
||
Comment 11•24 years ago
|
||
Comment 13•24 years ago
|
||
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!!!
Comment 15•23 years ago
|
||
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?
Comment 16•23 years ago
|
||
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.
Comment 17•23 years ago
|
||
Comment 18•23 years ago
|
||
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
Comment 21•23 years ago
|
||
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
Updated•23 years ago
|
Priority: P3 → --
Updated•23 years ago
|
Whiteboard: [CSS1-5.5.5][CSS1-5.5.10][CSS1-5.5.22]
Comment 24•23 years ago
|
||
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?
Comment 26•23 years ago
|
||
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
![]() |
||
Comment 27•23 years ago
|
||
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.
Comment 28•23 years ago
|
||
> "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)
Summary: [FILE] Cannot style INPUT TYPE=FILE button (CSS) → [FILE] Cannot style INPUT TYPE=FILE completely (CSS)
![]() |
||
Comment 30•23 years ago
|
||
> 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.
Reporter | ||
Comment 31•23 years ago
|
||
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.
Comment 32•23 years ago
|
||
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.
Comment 33•23 years ago
|
||
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.
Comment 35•23 years ago
|
||
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.
Comment 36•23 years ago
|
||
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.
Comment 40•23 years ago
|
||
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
Comment 42•22 years ago
|
||
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.
Comment 45•22 years ago
|
||
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.
Comment 46•22 years ago
|
||
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. ;-)
Comment 47•22 years ago
|
||
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.
Comment 48•22 years ago
|
||
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.
![]() |
||
Comment 49•22 years ago
|
||
> 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....
Comment 51•22 years ago
|
||
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.
![]() |
||
Comment 52•22 years ago
|
||
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?
Comment 55•22 years ago
|
||
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.
Comment 59•21 years ago
|
||
Comment 61•21 years ago
|
||
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?
Comment 62•21 years ago
|
||
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?
Comment 63•21 years ago
|
||
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.
Comment 64•21 years ago
|
||
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.
Comment 65•21 years ago
|
||
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.
Comment 67•21 years ago
|
||
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>
Comment 68•21 years ago
|
||
(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)
![]() |
||
Comment 69•21 years ago
|
||
> 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.
![]() |
||
Comment 72•21 years ago
|
||
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. ;)
Comment 74•21 years ago
|
||
(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).
Comment 75•21 years ago
|
||
Never mind, bz says bug 234607 isn't a dup, so I'm moving my last comment there.
Updated•21 years ago
|
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]
Updated•21 years ago
|
Flags: blocking1.7?
Updated•21 years ago
|
Assignee: rods → nobody
Status: ASSIGNED → NEW
Flags: blocking1.7?
Comment 82•20 years ago
|
||
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.
Comment 88•20 years ago
|
||
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...
Comment 91•20 years ago
|
||
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.
Comment 94•20 years ago
|
||
as you can see, the width of the textbox is wrong, therefore there is an ugly coloured patch
Comment 95•20 years ago
|
||
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
Comment 96•20 years ago
|
||
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
Reporter | ||
Comment 97•20 years ago
|
||
(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
Comment 98•20 years ago
|
||
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.
Comment 99•20 years ago
|
||
Please do not add useless advocacy comments to bugs. Use the forums to give feedback.
Comment 100•20 years ago
|
||
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
Comment 101•20 years ago
|
||
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!).
Comment 103•19 years ago
|
||
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
Comment 104•19 years ago
|
||
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.
Comment 105•19 years ago
|
||
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.
Comment 106•19 years ago
|
||
(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> <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.
Comment 107•19 years ago
|
||
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
Comment 109•19 years ago
|
||
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.
Comment 111•19 years ago
|
||
i'm just going to guess that https://bugzilla.mozilla.org/show_bug.cgi?id=258875 will be fixed before this.
Comment 115•18 years ago
|
||
<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.
Comment 119•17 years ago
|
||
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.
Updated•17 years ago
|
QA Contact: ian → layout.form-controls
Comment 122•17 years ago
|
||
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?
Comment 123•17 years ago
|
||
and for comparison here is how Safari (v3.0.4) render the file input styling.
Comment 125•17 years ago
|
||
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.
Comment 126•17 years ago
|
||
Comment 129•16 years ago
|
||
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.
Comment 130•16 years ago
|
||
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 :)
Comment 131•16 years ago
|
||
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!
Comment 132•16 years ago
|
||
> 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.
Comment 133•16 years ago
|
||
(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.
Comment 134•16 years ago
|
||
> 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.
Comment 135•16 years ago
|
||
(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.
Comment 136•16 years ago
|
||
(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!
Comment 137•16 years ago
|
||
(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.
Comment 138•16 years ago
|
||
(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...
Comment 139•16 years ago
|
||
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.
Comment 140•16 years ago
|
||
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?
Comment 141•16 years ago
|
||
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.
Comment 142•16 years ago
|
||
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.
Comment 143•16 years ago
|
||
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.
Updated•16 years ago
|
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.
![]() |
||
Comment 144•16 years ago
|
||
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.
![]() |
||
Comment 145•16 years ago
|
||
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 146•16 years ago
|
||
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?
Comment 147•16 years ago
|
||
(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.
![]() |
||
Comment 148•16 years ago
|
||
> 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.
Comment 149•16 years ago
|
||
(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...
Comment 150•16 years ago
|
||
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.
Comment 154•15 years ago
|
||
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.
Comment 156•15 years ago
|
||
(In reply to comment #155) > http://www.w3schools.com/CSS/pr_dim_width.asp That's my point: This doesn't work! Look here http://superpixel.ch/bugreport/mozilla-input-width/
Comment 157•15 years ago
|
||
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.
Comment 159•14 years ago
|
||
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.
Comment 160•14 years ago
|
||
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.
Comment 161•13 years ago
|
||
(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
Comment 162•13 years ago
|
||
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.
Comment 164•13 years ago
|
||
In fact, the width is often the recurrent problem before everything else.
Comment 165•12 years ago
|
||
Would be really nice to be able to set the width of the input manually by css.
Assignee | ||
Updated•12 years ago
|
Assignee | ||
Updated•12 years ago
|
Assignee | ||
Updated•12 years ago
|
Summary: Cannot style INPUT TYPE=FILE completely → Make regular CSS properties apply on <input type='file'>
Target Milestone: Future → ---
Assignee | ||
Comment 168•12 years ago
|
||
It should allow styling <input type=file> as much as any other browser without using pseudo-elements.
![]() |
||
Comment 169•12 years ago
|
||
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)
Assignee | ||
Comment 170•12 years ago
|
||
(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.
Assignee | ||
Updated•12 years ago
|
Attachment #732865 -
Flags: review?(bzbarsky)
![]() |
||
Comment 171•12 years ago
|
||
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+
Assignee | ||
Comment 172•12 years ago
|
||
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
Updated•12 years ago
|
Comment 173•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/132a424d1a28
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Updated•12 years ago
|
Keywords: dev-doc-needed
Assignee | ||
Comment 174•12 years ago
|
||
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?
Comment 175•12 years ago
|
||
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+
Comment 176•12 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/b31b08960f75 This has lots of conflicts on beta.
status-firefox22:
--- → unaffected
status-firefox23:
--- → fixed
status-firefox24:
--- → fixed
Keywords: branch-patch-needed
Updated•12 years ago
|
Assignee | ||
Comment 177•11 years ago
|
||
(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
Assignee | ||
Comment 178•11 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/1065d71fd46b
status-firefox21:
--- → unaffected
Comment 179•11 years ago
|
||
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
Updated•11 years ago
|
Comment 180•11 years ago
|
||
(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)
Updated•11 years ago
|
Keywords: branch-patch-needed
Assignee | ||
Comment 181•11 years ago
|
||
(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)
Comment 182•11 years ago
|
||
Ioana, can you please test this with Firefox 23 as well?
Keywords: qawanted
Comment 183•11 years ago
|
||
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
Comment 184•11 years ago
|
||
Will this allow repositioning of the BROWSE button to the right hand side (and outside of the text box) as it was before v22 ?
Comment 185•11 years ago
|
||
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; }
![]() |
||
Comment 186•11 years ago
|
||
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).
Assignee | ||
Comment 187•11 years ago
|
||
It would be great if discussing the anonymous content styling was done in bug 234607 instead of here.
Comment 188•11 years ago
|
||
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
Comment 189•11 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•