Closed Bug 290327 Opened 16 years ago Closed 8 years ago
CSS width applied incorrectly for the form input fields of type="file"
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 Mnenhy/0.7.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319 Mnenhy/0.7.1 For a given tag: <input type="file" size="12" style="width:15em"> a gap space, of width equal to the value of the CSS width property minus the value of the HTML size attribute, is shown next to the browse button. Reproducible: Always Steps to Reproduce: 1. Use two different values for the file input HTML size attribute and the CSS width property. Actual Results: A white gap next to the browse button is shown. Expected Results: The size of an input file form field should be equal to the value of the CSS width property (the value of the HTML size attribute should be ignored), and no gap should be present. An input file element width should be the same as the width of an input text element (see the testcase in IE). This is not a duplicate of the bug 52500. This is just a subset of it, which hopefully could be quickly fixed, whereas bug 52500 is also about formatting the text input and a button together (border, background, font) and probably would never be fixed due to the lack of CSS specification wording in this matter (see Boris Zbarsky comments: bug 52500, comment 27 and bug 52500, comment 30). This bug is filled in the spirit of bug 52500, comment 67 and bug 52500, comment 88 to achieve some fixes as soon as possible, without another five years of discussion.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Firefox 3.0 beta 5, the bug still exist.
I'll take a shot at this if someone can spec out the behavior we want here. One suggestion in bug 52500 was that the text input should change size to fit the overall width of the file input as specified in CSS. Things that need to be specified assuming we want to do that: 1) How does the size="" attribute interact with the width style? 2) What happens if the width style is smaller than the width of the button?
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
I think it should be something like: - The CSS width property must be applied to the whole input component (text + button) - The CSS property must take precedence over the HTML size attribute. That is, if both are defined, size must be ignored. - The width of the button should work like an implicit CSS min-width attribute, so the actual component width should be Max(CSS width, button width) Hope this helps, Rodrigo Ruiz
> The width of the button should work like an implicit CSS min-width attribute That would be a pretty serious violation of the CSS spec, actually. I'm not sure we want to do that.
No problem, my intention was to have a draft to work on :-) Another option would be to "hide" the text field (or just leave it with width:0px), and mimic the behaviour for simple buttons. This way, the width calculations would be something like: buttonWidth : min(width, defaultButtonWidth) textWidth : max(0, width - buttonWidth) Regards, Rodrigo PS: I have never seen the source code of Gecko, so I don't even know if this comment is useful at all :-D
Oh, it's useful. So if I understand the proposal correctly: 1) size attribute on textfield should only be used if the file input is auto-width. 2) When file input is not auto-width, then: a) button width is intrinsic width b) text input width is max(0, width - buttonWidth) c) If the total input width is too small for the button, it overflows (which is what happens right now anyway if the total width is too small). Sound about right?
(In reply to comment #10) > Sound about right? Yes, that is what Opera and WebKit do: the textfield is sized to fill the available width, CSS width overrides the size="" attribute. In the case of width < buttonWidth, both Opera and WebKit clip the button (overflow:hidden). That doesn't sound right.
(In reply to comment #10) > Sound about right? Yes, it looks right for me too :-) (In reply to comment #11) I think in this case this is a minor issue. Both clip and overflow make sense, and it will make a difference in only a very few cases. The usual case, at least from my experience, is that these fields are far wider than their button width. Said this, I would prefer to have consistent behaviour with other render engines: * It makes my web developing days easier ;-) * And any later change would modify the rendering of existing pages :-S So, I would say I prefer to clip rather than overflow.
> I think in this case this is a minor issue. Both clip and overflow make sense, > and it will make a difference in only a very few cases. The usual case, at > least from my experience, is that these fields are far wider than their button > width. They both may make sense, but only one is correct default behavior. The CSS 2.1 Candidate Recommendation says that the default value for overflow is visible. The expected results are demonstrated in the above attachment (https://bugzilla.mozilla.org/attachment.cgi?id=336844). It is also worth noting that clipping a file input would lead to the browse button being hidden. Thanks to the fix for bug 258875, it would result in what appears to be magic text box that pops up the file upload box. This isn't really a desirable behavior to allow, but the CSS standard still says overflow applies to "non-replaced block-level elements, table cells, and inline-block elements", which appears at first glance to include the <input type="file"/>. So basically, the CSS standard says the overflow should be visible. If someone wants to override it, they can set overflow:hidden, although this is not a desirable behavior.
Brad, you are totally right. With this, the proposal at comment #10 is the correct one :-)
<input type="file"> is sorta a replaced element as far as Gecko is concerned, for what it's worth.
This input file is really screwed guys.. please fix it as soon as possible and leave major improvements for later versions. I'm just trying to make the field a certain size and you'd think style="width:700px;" would work but it doesn't. I have to use <input name="infile" type="file" style="width:722px;" size="104" /> to make it look almost the same in both Firefox and IE. Also it's kind of ugly the way the Browse button is currently glued to the text field, it should have a couple of pixels of space between imho. I've already reported in another bug the fact that the input file field is always white background which makes it hard to read when your site is designed to have yellow text on brown background for example. As for later versions: maybe there could be an option implemented/mozilla specific css rule to show the browse button below the input field and aligned to the right of the input field. This way all text fields would have the same width on a form and would probably look better. well... it's anyway better than Chrome's input field which doesn't follow any rule but please fix it guys..
I should add, to make matters worse, size varies between platforms. For example, if you set size="75" on Firefox for Windows, you need to set the size to a different value on Firefox for Mac in order to look equivalent.
size="NN" will size depending on the font for the control (just like text inputs), which varies by platform settings, user preferences, etc.
Hi, what about this bug? :) I have last beta for now - ff 10 beta6, and this bug are present. See here for simple testcase: http://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_size_css if I replace input type="text" to input type="file" and set style="width:150px" to 250px, 350px and so on, real field size (rendered on right side) are not change it's size. Is a css code in testcase wrong, or it is a bug with very long history and not resolved?
This should be fixed by bug 52500.
Assignee: bzbarsky → mounir
Priority: P4 → --
Hardware: x86 → All
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 8 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 52500]
Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20130521 Firefox/24.0 Attachment 180720 [details] is worse than before now, text unreadable on dark background
You need to log in before you can comment on or make changes to this bug.