Closed Bug 610733 Opened 9 years ago Closed 6 years ago
combobox (<select>) should vertically center text in the display area when a non-default height is set
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:188.8.131.52) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0C) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:184.108.40.206) Gecko/20101026 Firefox/3.6.12 ( .NET CLR 3.5.30729; .NET4.0C) When the height of a form select box is specified (say, in pixels), rather than letting the select box height be derived from the height of the font inside it, you cannot vertically center the text via the combination of height/line-height, or via the use of vertical-center: middle. There seems to be no way to vertically center text inside a height-specified select box, like you can with a text input box. Reproducible: Always Steps to Reproduce: 1. specify height of select box via css 2. specify line-height as the same value 3. specify smaller font size; text will not be centered as in input box styled the same way. Actual Results: The text is near the top of the select box, rather than centered. Expected Results: Text should be vertically centered in the select box, in the exact same way it is in a text input box.
You can't center text in a text input yourself. They do it automatically, but there's no user control over it. In any case, in a <select> the text is in an inline-block inside the <select>... CSS doesn't really provide a way to handle this situation (since <select> is a replaced element). Note that even if the text were not inside an inline-block, vertical-align would not do what you want since this is not a block-level box.
> You can't center text in a text input yourself. They do it automatically, but > there's no user control over it. Not true in the condition I specified. If you specify the height of the input (rather than letting it create the height off the size of the font), then you can easily wind up with a text input that is much taller than the font is. To vertically center this, you specify the height and line-height of the input, and the font is always centered in it, just like with any block-level element like a div. Works great in this scenario. > In any case, in a <select> the text is in an inline-block inside the > <select>... CSS doesn't really provide a way to handle this situation (since > <select> is a replaced element). Note that even if the text were not inside an > inline-block, vertical-align would not do what you want since this is not a > block-level box. Even if I specify the select as display:block, nada. Nothing I've been able to discover will allow me to style a select in this design scenario to make it look good like in other non-IE browsers. (IE has other issues with select boxes, of course.)
> can easily wind up with a text input that is much taller than the font is Yes, and on trunk the text is vertically centered in it by default, and unaffected by line-height as far as I can see. > Even if I specify the select as display:block, nada. It's a replaced element. The rendering of its insides is not under CSS control....
> Yes, and on trunk the text is vertically centered in it by default, and > unaffected by line-height as far as I can see. I'm not sure what 'trunk' is. Is that current code or current dev branch? The current version of FF doesn't appear to vertically center the text so much as build the select box around whatever the height of the font is. If this is fixed in an upcoming version of FF, do you know if it's for FF 3.something or 4.something?
"trunk" is what will become Firefox 4. It does not vertically center text in the <select>, but does vertically center it in text inputs.
> "trunk" is what will become Firefox 4. It does not vertically center text in > the <select>, but does vertically center it in text inputs. So in FF 4, you can't specify the height of text inputs and selects and have it look right. Just like now. I don't really care if it's 'automatically' vertically centered in text inputs, as I can fix that now with CSS. The problem is select boxes with non-default heights look sloppy now. Other browsers do this correctly, so it has to be possible. For now, the only way to make this look right is to completely replace the select via js, which is a bit extreme.
The problem is browser's default user agent stylesheet. It has the following rule for select boxes: line-height: normal !important; The "important" notation prevents you from overriding the line height. I don't know why it is there. It's annoying and limits your ability to style forms how you want. You end up having to do ugly hacks with padding.
> I don't know why it is there. Because sites set bogus line-heights on <select> all the time and expect it to be ignored. And browsers do ignore it, because otherwise sites end up broken. See bug 349259 comment 42 for some data. In any case, resummarizing this to cover the real issue coment 6 points out.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: select box doesn't respond to height/line-height/vertical-align CSS to vertically center text → combobox (<select>) should vertically center text in the display area when a non-default height is set
This is a real drag, I want to just specify height, but instead I have to use padding which ends up padding the arrow as well.
I think we can reconsider the reasoning stated on the comments from 2011. In 2013, browsers such as Chrome do not ignore line-height for <select> elements anymore and do vertically center the text based on that. Here is a simplified test case: http://jsfiddle.net/Q5fc7/4/ Expected results: - Firefox should display the text in the middle of a combobox with custom height, like chrome and safari. Actual results: - Firefox displays the text at the top (line-height 14px) of a combobox with custom height, regardless of the visual height of the element.
Correction to this problem would be very appreciated.
+1 to fix this issue.
So the basic implementation issues here are as follows: 1) vertical-align can't be used to vertically center text in a block, as far as I can tell. 2) line-height cannot be easily set to the height of the element (which is really what we want here) if the element's height is itself a percentage of the parent's height. David, is there a sane CSS way to get the arbitrary-height auto-center-the-text behavior we want here?
Hello, This was reported 4 years ago (2010), any news about fixing this horrible bug? When should we expect it to work properly in Firefox? Thank you!
Does line-height: -moz-block-height work? It seems like it ought to at first glance, although I'm not sure if it's exactly the right number.
> Does line-height: -moz-block-height work? Yes, that's exactly what we need here.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Comment on attachment 8396160 [details] [diff] [review] Vertically center the text in the combobox display area when a non-default height is set for the combobox. r=dbaron
Attachment #8396160 - Flags: review?(dbaron) → review+
(A test would also be good if there's a reasonable way to write one.)
I haven't thought of one yet. :(
Maybe with some padding-top bits.... will see if that actually passes on try.
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
is this bug really fixed? i still don't see it
Are you using a nightly or Aurora build?
Verified BROKEN! Installed a fresh copy on a never-installed-Firefox-for-Edge-testing-only VM and tested out an inline style with !important and the built in developer tools in Firefox 52 ESR still showed the internal forms.css file as overriding author styling. There are plenty of threads (especially on SO) about people beating their heads over this. Please just remove the line-height property from the forms.css file. Not every website UI can use 200 pixel tall select elements, some of us realize how to use subtle styling.
Please file a new ticket with clear steps to reproduce and a test case - see https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines for more information. This ticket was closed more than 3 years ago and the codebase has changed a bit in the meantime.
You need to log in before you can comment on or make changes to this bug.