Last Comment Bug 349259 - CSS Property 'line-height' has no effects on input text fields
: CSS Property 'line-height' has no effects on input text fields
Status: RESOLVED FIXED
[just removing !important breaks yout...
: compat, dev-doc-needed
Product: Core
Classification: Components
Component: Layout: Form Controls (show other bugs)
: Trunk
: x86 All
: -- normal with 47 votes (vote)
: mozilla30
Assigned To: David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch)
:
Mentors:
http://host.epper.org/firefox/line-he...
Depends on: 425004 634649 481751 658982 985157
Blocks: 82265
  Show dependency treegraph
 
Reported: 2006-08-18 16:44 PDT by Andrea Zilio
Modified: 2014-11-17 10:16 PST (History)
53 users (show)
bzbarsky: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
30+


Attachments
patch removing important on line-height normal (738 bytes, patch)
2009-03-25 19:26 PDT, Karl Tomlinson (:karlt)
no flags Details | Diff | Splinter Review
Test case showing inconsistent CSS behaviour due to element type difference (704 bytes, text/html)
2010-04-20 08:21 PDT, Rob Moss
no flags Details
Test case rendering in Trident (1.08 KB, image/png)
2010-04-20 08:46 PDT, Rob Moss
no flags Details
Test case rendering in Presto (1.08 KB, image/png)
2010-04-20 08:46 PDT, Rob Moss
no flags Details
Test case rendering in Webkit (1.08 KB, image/png)
2010-04-20 08:46 PDT, Rob Moss
no flags Details
Test case rendering in Gecko (1.07 KB, image/png)
2010-04-20 08:47 PDT, Rob Moss
no flags Details
Like so (2.06 KB, patch)
2011-04-05 15:12 PDT, Boris Zbarsky [:bz]
dbaron: review+
Details | Diff | Splinter Review
Testcase (1.75 KB, text/html)
2011-04-12 02:15 PDT, Boris Zbarsky [:bz]
no flags Details
Screenshot of bz’s test case in IE9 standards mode. (10.08 KB, image/png)
2011-04-12 02:27 PDT, Mathias Bynens
no flags Details
Screenshot of bz’s test case in IE9 quirks mode. (7.57 KB, image/png)
2011-04-12 02:27 PDT, Mathias Bynens
no flags Details
Testcase using <button> too (2.10 KB, text/html)
2011-05-02 19:41 PDT, Boris Zbarsky [:bz]
no flags Details
With that change (1.62 KB, patch)
2011-05-03 11:17 PDT, Boris Zbarsky [:bz]
no flags Details | Diff | Splinter Review
Simple test case the 4 other 'big' browsers pass, but not Firefox 5 (703 bytes, text/plain)
2011-06-27 02:03 PDT, Kristiaan Van den Eynde
no flags Details
On the top, Firefox 9.0.1, bottom : Chrome 16 (132.31 KB, image/png)
2012-01-24 02:48 PST, KLEIN Stéphane
no flags Details
Testcase (3.59 KB, text/html)
2014-01-28 14:44 PST, Mats Palmgren (vacation)
no flags Details
wip (6.42 KB, patch)
2014-01-28 14:52 PST, Mats Palmgren (vacation)
no flags Details | Diff | Splinter Review
patch 1: Add an nsIContent* parameter to nsHTMLReflowState::CalcLineHeight (10.00 KB, patch)
2014-03-12 13:30 PDT, David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch)
bzbarsky: review+
Details | Diff | Splinter Review
patch 2: Prevent html:input elements from having a line-height smaller than 1 (1.31 KB, patch)
2014-03-12 13:31 PDT, David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch)
bzbarsky: review+
Details | Diff | Splinter Review
patch 3 - Allow pages to override line-height on form controls, except for <select> (1.15 KB, patch)
2014-03-12 13:31 PDT, David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch)
no flags Details | Diff | Splinter Review

Description Andrea Zilio 2006-08-18 16:44:41 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

Impossible to style an <input type="text"> with a specific line-height, even if using the "!important" rule.

Reproducible: Always

Steps to Reproduce:
1.Just open the web page linked here and see the example

Actual Results:  
The text into the text field doesn't have the line-height specified by te CSS.

Expected Results:  
The browser should use the line-height value to "specify the minimal height of line boxes within the element".
In this case, line-height=height, the browser should center vertically the text

Running Microsoft Windows XP Professional with Firefox 1.5.0.6
Comment 1 Phil Ringnalda (:philor, back in August) 2006-08-18 17:13:15 PDT
That seems to be intentional: see bug 82265 and bug 155483
Comment 2 Daniel.S 2009-02-07 07:45:42 PST

*** This bug has been marked as a duplicate of bug 82265 ***
Comment 3 Boris Zbarsky [:bz] 2009-02-08 05:32:04 PST
This isn't really a duplicate of the bug that made this not work.

This is, however, wontfix, per the discussion in that bug.
Comment 4 Karl Tomlinson (:karlt) 2009-03-04 23:20:31 PST
The comment re textarea in bug 243100 comment 3 would seem to also apply here.

FWIW, IE7 styles input elements according to line-height, but in a way that requires height to also be specified for sensible behavior.  And line-height needs to be specified on the input element, as it is not inherited.
Comment 5 Boris Zbarsky [:bz] 2009-03-05 06:38:22 PST
> The comment re textarea in bug 243100 comment 3 would seem to also apply here.

No, since the text input doesn't have multiple lines of text in it.  

I don't see that anything has changed since bug 82265.  In my opinion this should still be wontfix.
Comment 6 Karl Tomlinson (:karlt) 2009-03-05 12:09:20 PST
(In reply to comment #5)
> > The comment re textarea in bug 243100 comment 3 would seem to also apply here.
> 
> No, since the text input doesn't have multiple lines of text in it.

I don't see the reason for different behaviour between multiple lines and one line.  The line-height property is just as applicable to one line.

Increasing line-height seems a sensible way of increasing the clip area when text might extend beyond the nominal ascent/descent.

> I don't see that anything has changed since bug 82265.  In my opinion this
> should still be wontfix.

Well, textarea has changed since bug 82265 and now we have an inconsistency between textarea and input.

There doesn't seem to be much reasoning provided for the change in bug 82265 apart from: there's no spec that says what we should do, and "not doing it is a compat nightmare that we should not be causing".  compat with what?
Comment 7 Boris Zbarsky [:bz] 2009-03-05 12:33:41 PST
Compat with the IE and the web.  Note that that referred to setting line-height on inputs per se, not to making it !important.

I _might_ be convinced to remove the !important if IE in fact allows small line-heights.  But note that this will be subject to sites breaking if we ever change inputs to not have a block inside, so we'd also be causing compat issues with ourselves....
Comment 8 Karl Tomlinson (:karlt) 2009-03-05 12:51:13 PST
(In reply to comment #7)
> Note that that referred to setting line-height
> on inputs per se, not to making it !important.

OK, thanks.

> I _might_ be convinced to remove the !important if IE in fact allows small
> line-heights.

Removing important is all that I would suggest.

Small line-heights in IE7 cause the top and bottom of the text to be clipped.

> But note that this will be subject to sites breaking if we ever
> change inputs to not have a block inside, so we'd also be causing compat issues
> with ourselves....

That would depend on whether the replacement implementation respected line-heights.  I'm not aware of any reason why our text frame implementation should not respect line-heights, for example.
Comment 9 Boris Zbarsky [:bz] 2009-03-05 12:53:41 PST
> Small line-heights in IE7 cause the top and bottom of the text to be clipped.

Hmm.  In our impl, so far, it'd just clip the bottom...  Also, have you tested behavior on Mac and Linux, where the padding situation is much worse than windows in the native controls?
Comment 10 Karl Tomlinson (:karlt) 2009-03-25 19:26:17 PDT
Created attachment 369414 [details] [diff] [review]
patch removing important on line-height normal

This is a patch for testing.

But I'm thinking that it actually would make more sense if the text-control just set the line-height of its text appropriately based on its client area height (derived from the CSS height property, and, in quirks mode, borders).  I'll put examples in bug 481751.

Perhaps even if the code chooses the line-height of the text, recognizing the line-height property on the control may be useful for setting an intrinsic height for the control.  Or perhaps it is clear that controls are inline replaced elements and the height should be set with the "height" property.
Comment 11 Rob Moss 2010-04-20 08:21:57 PDT
Created attachment 440225 [details]
Test case showing inconsistent CSS behaviour due to element type difference

At the very least, Presto, Trident and Webkit show two pretty much identical squashed buttons. I've only made them really squashed to exacerbate the difference between an input and a non-input. I can't find anywhere in any standard that says you shouldn't be able to read what's in the input box just as well as what's in the link, and nor can I think of a good reason why the current behaviour would be desirable, despite having looked at all the past test cases on bugs related to this one. Gecko is the only layout engine that does this, as far as I can work out, which is a compatibility nightmare we just shouldn't be causing (to quote a previous poster on an earlier bug).
Comment 12 Boris Zbarsky [:bz] 2010-04-20 08:32:54 PDT
The testcase from comment 11 looks pretty much identical to me in Gecko and Webkit (Safari on Mac) and doesn't seem to be related to this bug at all.
Comment 13 Rob Moss 2010-04-20 08:46:04 PDT
Created attachment 440230 [details]
Test case rendering in Trident
Comment 14 Rob Moss 2010-04-20 08:46:19 PDT
Created attachment 440231 [details]
Test case rendering in Presto
Comment 15 Rob Moss 2010-04-20 08:46:51 PDT
Created attachment 440232 [details]
Test case rendering in Webkit

Webkit has a minimum top padding of 1 pixel, unlike Presto and Trident.
Comment 16 Rob Moss 2010-04-20 08:47:36 PDT
Created attachment 440233 [details]
Test case rendering in Gecko

Gecko puts 5 pixels above the text and chops off the bottom half of the text.
Comment 17 Boris Zbarsky [:bz] 2010-04-20 09:01:28 PDT
Not over here it doesn't.  The exact behavior will depend on the OS and the OS theme being used.

And again, that has nothing to do with this bug.  Please file a separate bug if you strongly feel about your issue.
Comment 18 Rob Moss 2010-04-20 09:18:27 PDT
If I take the !important off line-height: normal in forms.css, it uses a line-height equal to the height of the box, as specified by the CSS rule in the <style/> tag. It then renders identically, pixel-for-pixel, to how Presto and Trident render it. The exact behaviour with the current rule in forms.css will obviously depend (due to "line-height: normal;" being underspecified) on the OS and OS theme being used, but that's a pointless argument - akin to "This shoe doesn't fit everyone" / "Well it fits me".

The test case I've attached exactly demonstrates the behaviour reported in the original report, and is fixed by the proposed patch from Karl.

How does this have nothing to do with this bug? What am I missing?
Comment 19 Boris Zbarsky [:bz] 2010-04-20 09:33:28 PDT
Ah, I thought your issue was with the padding, not the line-height.  OK, then.
Comment 20 Rob Moss 2010-04-20 10:39:32 PDT
In that case I probably should have expressed myself better in the first place. :-)
Comment 21 Renaud Lideln 2010-10-06 02:33:46 PDT
Please just remove that '!important' part, that's all !
It's a quick fix, nope ? :)
Comment 22 Renaud Lideln 2010-10-06 02:37:22 PDT
I know there were more important things to fix, of course, but 4 years just to remove a single word, it's so sad... I would do it if I could :)
Comment 23 Boris Zbarsky [:bz] 2010-10-06 07:15:16 PDT
Removing is easy, sure.  Are you volunteering to get the websites that will break as a result updated?  Or to do the investigation into what sites these would be?  You _did_ read this bug and the dependent bugs?

Again, I'd be fine with removing this early in an alpha cycle and seeing what the fallout is.  But let's not pretend this is a small-time-investment change, ok?
Comment 24 Renaud Lideln 2010-10-06 07:48:42 PDT
I read the bug, and I saw that except for the Japanese font thing, the dependent bugs were fixed.

I am not a Firefox developer, but I don't think websites will "BREAK" because we removed the "!important" in the "line-height: normal" thing, because :
- either the developers did not specify and line-height, in which case it won't change anything (the base rule will still apply)
- or the developers specified a line-height, in which case it will finally work !
The only case it would "bug" (IMHO) is when developers used the padding hack to workaround that firefox bug (just like so many do for internet explorer bugs).
And the result would not be that awful neither, maybe a few pixels vertical alignment change for some websites.

I just can't help you develop firefox, that's all. But if you list me the 20 most important websites you want me to check against that change, I will do it with pleasure (although I consider it's the website developer responsibility to check his website with new browsers regularly).

Again, I'm not a Firefox developer and I won't pretend I am. But, as a web developer, I don't think removing the "!important" would be harmful, and also, the bug is open for 4 years...

I will of course leave you, firefox developers, think of what the best solution would be, but please give a second thought considering fixing (or not) that bug.

Kind regards,
Comment 25 Boris Zbarsky [:bz] 2010-10-06 07:52:39 PDT
> But if you list me the 20 most important websites

There's the problem.  The number of sites that needs to be checked is several orders of magnitude bigger than "20".

> although I consider it's the website developer responsibility

Thank you for a good morning laugh.  ;)  Most website developers treat their sites as write-once (and this includes many major company sites).  They only get changed when being wholly redesigned...
Comment 26 Rasmus Fløe 2010-10-27 14:20:41 PDT
On this exact matter of using internal css stylesheets with properties using "!important" Firefox is letting web developers down bigtime with absolutely no way of overriding them. Very frustrating (think IE)!

I can understand why you would bring on the breakage argument - but I'd be hardpressed to come up with any realistic scenario that would cause any type of breakage. A scenario where NOT being able NOT to set line-height in Firefox breaks a page??

Firefox is the only browser that has this unfortunate behaviour... Affected elements with "line-height: normal !important": input, button, select, option and optgroup.

At the very least you could give us a way out. Eg, make it possible to override "!important" by setting "-moz-appearance: none;".
Comment 27 Kyle Adams 2010-12-30 12:55:29 PST
I'll throw my hat in with the "please remove !important" group and +1 the "really, what's the worst that could happen" argument on compatibility. I'm getting tired of foregoing line-height in favor of padding when styling submit buttons. I'm not sure what the post-FF4 dev timeline looks like right now, but it seems like there might be an opportunity there to put the change into an early alpha cycle, correct?
Comment 28 Rob Moss 2010-12-30 13:19:09 PST
It does seem like a good opportunity. Seeing as this bug has sprawled out into a few others, can Boris (or whoever) please point me in the direction of the original test case this rule fixed? I'll happily run it through my full set of VMs with pretty much every major browser release since IE 3.0 - once we know which browsers we're breaking backwards compatibility with we can make a better judgement. I would argue that if it's just old unsupported versions (pre-6.0) of IE we probably shouldn't care - the rest of the world doesn't any more.
Comment 29 Boris Zbarsky [:bz] 2010-12-30 15:06:18 PST
See bug 82265 and the 9 bugs it blocks for the original set of testcases.
Comment 30 Boris Zbarsky [:bz] 2010-12-30 15:06:51 PST
And note that that information is already present in comment 1 of this bug...
Comment 31 Rob Moss 2010-12-30 20:01:20 PST
Thanks Boriis - I was aware of comment #1 - I'm just acutely aware of the fact, given my line of work, that things that carry on for an extended length of time usually end up with a substantial level of knowledge being betrothed upon the owner and too much going unrecorded. I'll get some testing done on older browsers during the week commencing January 4th.
Comment 32 Robert 2011-01-13 10:58:54 PST
+1 @ removing !important.

( See, for example: http://stackoverflow.com/questions/2133740/firefox-3-6-and-css-difference-from-previous-versions-of-firefox-3-5-and-back and http://www.cssnewbie.com/input-button-line-height-bug/ )

Just my two cents, since this first started occurring in FF 3.6, it has been driving me batty as a CSS guy.  It's *okay* at times to specify approximate heights using padding, but when exactness is needed (as is often the case in industry), padding just doesn't cut it.
Comment 33 Kristiaan Van den Eynde 2011-04-05 02:20:46 PDT
Firefox 4 stylesheet still shows line-height: normal !important; (resource://gre-resources/forms.css). Could we please get this fixed?

As others have pointed out, there won't be that many websites breaking because:
A) they didn't touch line-height, so 'normal' stays in effect
B) they -did- change line-height, but because of this bug they never got the intended result in FF (they do in other browsers, even IE!)

In case B), the padding fallback that was implemented to 'fix' FF layout would hardly have any effect. (maybe a pixel or two)

The real question is: do you really want to leave such a frustrating bug in your browser, just because the work-arounds people had to implement (because of the bug!) may look a little odd?
Comment 34 Boris Zbarsky [:bz] 2011-04-05 07:11:26 PDT
> they do in other browsers, even IE!

Not quite.  Do read bug 82265, please.
Comment 35 Boris Zbarsky [:bz] 2011-04-05 07:15:43 PDT
Actually scratch that.  Comment 23 is the relevant thing here.  I'll see about getting this into Firefox 6.
Comment 36 Kristiaan Van den Eynde 2011-04-05 07:24:39 PDT
My comment about it working in IE was based on the link provided by Robert on 2011-01-13 (http://www.cssnewbie.com/input-button-line-height-bug/).

Anyway, cheers about trying to put it in future FF versions, what a relief :)
Comment 37 Renaud Lideln 2011-04-05 07:59:32 PDT
I agree, thank you for doing it !!
I'm at your disposal if you need testers later. Feel free to contact me.
Comment 38 Boris Zbarsky [:bz] 2011-04-05 15:12:44 PDT
Created attachment 524095 [details] [diff] [review]
Like so

David, what do you think of doing this after the April 12 branch?
Comment 39 Rasmus Fløe 2011-04-05 16:29:04 PDT
button, select, option and optgroup also suffer from line-height: normal !important. (as mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=349259#c26)
Comment 40 Boris Zbarsky [:bz] 2011-04-05 16:32:22 PDT
> button, select, option and optgroup

Did you read the patch?  It changes button and select.  I don't think we want to change option+optgroup pending spec work; browser behavior when those are styled is _very_ non-interoperable.
Comment 41 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2011-04-11 15:40:20 PDT
Comment on attachment 524095 [details] [diff] [review]
Like so

This seems fine assuming that text inputs, selects (both combobox and listbox) and buttons resize themselves appropriately when the line-height changes.

buttons look like they should be fine given that <button> works fine.  Likewise for text inputs and text areas.  But they should nonetheless be tested.

Have you tested selects, in both forms, including their behavior?

r=dbaron if you have tested those things -- though some reftests would be good as well.
Comment 42 Boris Zbarsky [:bz] 2011-04-12 02:14:52 PDT
So I just did some testing, and I'm not entirely convinced about this patch.

I tested WebKit (in multiple incarnations) and Presto; I don't have a Trident-based on hand.  The results are:

1)  In both WebKit and Presto line-height is completely ignored for <select>
    elements.
2)  Opera also completely ignores it on buttons and text inputs.
3)  WebKit ignores it on natively themed buttons but allows it on buttons that
    have dropped native theming.
4)  For text inputs, themed or not, WebKit allows line-height to _increase_ 
    the height of the text input, but not decrease it.

Given that, there is a real danger of text being invisible in inputs in Gecko, with this patch, but visible in the other browsers.  This is clearly a bad thing, since web sites could be relying on it being visible.

I'll attach my testcase; I'd appreciate a screenshot of what IE does with it (ideally in both standards mode and quirks mode).
Comment 43 Boris Zbarsky [:bz] 2011-04-12 02:15:39 PDT
Created attachment 525338 [details]
Testcase
Comment 44 Boris Zbarsky [:bz] 2011-04-12 02:16:30 PDT
Oh, and based on that testcase, I think we should revert the change for <select>, at least: it doesn't really work very well at all if we allow line-height on that to be changed.
Comment 45 Mathias Bynens 2011-04-12 02:27:12 PDT
Created attachment 525340 [details]
Screenshot of bz’s test case in IE9 standards mode.
Comment 46 Mathias Bynens 2011-04-12 02:27:36 PDT
Created attachment 525341 [details]
Screenshot of bz’s test case in IE9 quirks mode.
Comment 47 Boris Zbarsky [:bz] 2011-05-02 19:36:17 PDT
Ah, interesting.  It appears that there may also be differences here based on display type; in particular Opera treats display:block and display:inline buttons differently...
Comment 48 Boris Zbarsky [:bz] 2011-05-02 19:41:40 PDT
Created attachment 529629 [details]
Testcase using <button> too

Actually, I was wrong.  What Opera does is that it allows line-height to change unthemed <button> but not <input type="button">...
Comment 49 Boris Zbarsky [:bz] 2011-05-03 11:15:01 PDT
OK, so I'm going to leave the line-height style on <select> but take it off the others, I think.  If we run into trouble it'll probably be in quirks mode per the IE screenshots, and we can think about adding a quirk then.
Comment 50 Boris Zbarsky [:bz] 2011-05-03 11:17:00 PDT
Created attachment 529766 [details] [diff] [review]
With that change
Comment 51 Renaud Lideln 2011-05-03 11:23:05 PDT
Yay to that ! Thanks and congratulations ! :)
Comment 52 Boris Zbarsky [:bz] 2011-05-04 19:33:28 PDT
Note to self: need to fix test_animations.html as well.
Comment 53 Boris Zbarsky [:bz] 2011-05-05 13:37:58 PDT
Pushed http://hg.mozilla.org/mozilla-central/rev/e5668cb2a02f
Comment 54 Boris Zbarsky [:bz] 2011-05-23 06:13:12 PDT
Aaand, the first report of a site being broken due to this change.  Youtube, to be precise.
Comment 55 Boris Zbarsky [:bz] 2011-05-23 06:54:50 PDT
In particular, YouTube is relying on the fact that no browser (based on my testcase above) allows a line-height setting to reduce the height of an input.  They're setting a too-small line-height and depending on it being ignored.
Comment 56 Boris Zbarsky [:bz] 2011-05-23 09:05:50 PDT
sony.jp is also broken, for the same reason.

I'm going to back out the text input part of this bug, effective immediately.  It presumably can't happen unless we implement WebKit's weird "don't let it decrease the height" behavior, which I'm not sure we want to do.

It _might_ also be enough to copy IE/WebKit's weird padding behavior as described in bug 634649.  That would help Sony, but not Youtube (since the former just depends on the text being visible while the latter depends on the actual input height).
Comment 57 Boris Zbarsky [:bz] 2011-05-23 09:09:06 PDT
If we decide we _do_ want WebKit's behavior here, I think just putting another kid inside the <input> and styling it "line-height: normal" would do the "right" thing (in particular, make the <input> height not shrink due to reduced line-height).
Comment 58 Boris Zbarsky [:bz] 2011-05-23 09:19:49 PDT
More precisely, I'm backing out everything except the <button> part.  So we will effectively match Opera's behavior after that.
Comment 59 Boris Zbarsky [:bz] 2011-05-23 12:48:08 PDT
Did that in bug 658982.
Comment 60 Steven Hartland 2011-06-01 05:26:47 PDT
I cant believe this is still hasnt been fixed, I mean serious, raised in 2006 and we now 2011 and you still cant set a line height on a button.

Its worse than that though with FF4 as its "normal" line height depends on if its got hardware accel enabled see:
https://bugzilla.mozilla.org/show_bug.cgi?id=628601

The stated fix is for designers to specify a line height if they need to get correct layout, but with this bug that's not possible for the effected elements.
Comment 61 Boris Zbarsky [:bz] 2011-06-01 07:54:35 PDT
> and you still cant set a line height on a button

1)  This bug is about line-height on _text_ inputs.
2)  In Gecko 6 (currently on the Aurora channel) you can set line-height on a
    <button>.
3)  Please read the whole bug before commenting next time, ok?
Comment 62 Steven Hartland 2011-06-01 09:22:25 PDT
If you "read the whole bug" you will see multiple references to buttons, there's even a test case for buttons attached.

So quite valid don't you think; especially as they are caused by the same issue,  which is _still_ present in the latest release.
button, input[type="reset"], input[type="button"], input[type="submit"] {
line-height: normal !important;
}

Buttons may well be fixed in an unreleased version, but that doesn't help users or developers at this current time and for this to have taken 5 years is quite unbelievable, so I would suggest its you that need to go back and read contents of this report and the comments.
Comment 63 Kristiaan Van den Eynde 2011-06-27 02:03:21 PDT
Created attachment 542112 [details]
Simple test case the 4 other 'big' browsers pass, but not Firefox 5

In the following -simple- attachment, the following behaviour would be expected:
- Both inputs should be eighteen pixels of height (18+0 and 16+1+1)
- In the submit input, there should be three pixels of space above and below the text
- In the text input, there should be two pixels (vertically) of space between the text and the border

Currently:
- Chrome 12 and IE9 render this perfectly
- Safari 5.0.5 and Opera 11.11 render nicely
- Firefox 5 renders the test with all text 'glued' to the bottom

I know you stated this bug is about _text_ inputs, Boris, but clearly it relates to all input variants. Not coincidentally, the '!important' keyword is placed within a rule on the 'input' selector..

Also: could we please keep it civil? There's been several patronizing or rude replies in this thread already, whereas we're all trying to create a better web here. (Or at least, we should be.)
Comment 64 Boris Zbarsky [:bz] 2011-06-27 07:11:23 PDT
Kristiaan, the alignment issue is a separate issue, actually.  Please file a separate bug on it?  The Chrome/IE9 rendering is not something that can be expressed in CSS, so we would need to just stop using CSS styling for input internals entirely to do that.  While that may be worthwhile (though a complete rewrite of the way form control layout works is a big undertaking with what looks like small payoff in this case), this bug as filed is about the lack of effect of line-height on the height of text inputs (which is not an issue in your testcase, since you set their height explicitly).  The solutions for the two problems are likely different...
Comment 65 Lars Gunther 2011-08-23 04:15:07 PDT
While this comment is of no value for implementing a fix to this bug (and thus somewhat spammy) I think developers who have found this bug searching for an explanation/solution to their problem will find this of value:

http://www.456bereastreet.com/archive/201108/line-height_in_input_fields/
Comment 66 George Katsanos 2011-08-27 14:47:24 PDT
I ready almost all comments, I do not understand why we're still talking about it:
Using !important (!!) in the UA stylesheets is absolutely unacceptable and violates any good practice in CSS. Firefox can declare any kind of line-height value in any element it wants, but without making it impossible to override with !important. For god's sake. 
Regarding the "if we remove it websites will break" it sounds pretty much IE/MS talk to me. Plus, as many of the previous commentators wrote, the worst 'breakage' that can happen, is minor. (if any)
One more vote to fix this ASAP.
Comment 67 Boris Zbarsky [:bz] 2011-10-26 08:36:47 PDT
For people who want to track <input type="button"> as opposed to text inputs, bug 697451 now covers it.
Comment 68 philip 2012-01-11 13:02:19 PST
I understand the hesitance in removing the !important from the UA stylesheet (I don't agree, but I understand), yet I still don't understand why another solution hasn't been implemented after all this time.

Why can't there be a -moz-input-line-height property or some equivalent that can override the standard line-height for those developers who want to be able to set their own line-height on input elements?

Currently it's very frustrating to not be able to get equal heights for selects, buttons, and inputs of type button or submit consistently in all browsers. Very frustrating indeed.
Comment 69 Ian Storm Taylor 2012-01-23 19:33:15 PST
Again coming up against this bug. It is ridiculous for a UA stylesheet to set !important declarations that cannot be overridden.
Comment 70 KLEIN Stéphane 2012-01-24 02:48:25 PST
Created attachment 591049 [details]
On the top, Firefox 9.0.1, bottom : Chrome 16

You can see that line-height work very well on Chrome and no effect on Firefox.
Comment 71 naktinis 2012-04-25 02:44:04 PDT
And what about <select> elements. I think the same thing applies there as well.
Comment 72 coues Ludovic 2012-06-02 13:28:08 PDT
what about a -moz-min-line-height ?
it would allow to reproduce the webkit behavior of not allowing line-height to be reduced.
Comment 73 Josh Olson 2012-10-19 10:19:18 PDT
Boris (or anyone else), is there still a hold up on <option> being supported or is it just a priority thing? Could you please elaborate on "I don't think we want to change option+optgroup pending spec work; browser behavior when those are styled is _very_ non-interoperable." -- namely the non-interoperable part? Forgive my naivety, but if other cross-OS browsers are supporting <option> line-height, why can't Firefox?

Also, could we get a response in regards to all the workarounds suggested (i.e. -moz-min-line-height, -moz-input-line-height, -moz-appearance)?
Comment 74 Matt Giacomazzo 2013-01-08 11:54:49 PST
It is cross-browser issues such as this which is why Firefox continues to lose market share among myself and my peers. We work with one of Inc 5000's fastest growing web development companies and with the advent of IE9 we are seeing in some cases fixes for Firefox eating up more development time than that is needed for IE9. We are not a hack shop. We employ many best practices around Drupal's standards supported and forward leaning framework called Omega. Used for many professional and large scale sites around the web.

I strongly urge the community to be more responsive to bugs such as these.

In the meantime some good documentation on a technique to deal with this issue would be appreciated.
Comment 75 Matt Giacomazzo 2013-01-08 11:58:34 PST
In addition Eric Meyer, one of the fathers of modern CSS, also states that line-height: normal is anything but. http://meyerweb.com/eric/thoughts/2008/05/06/line-height-abnormal/ As a browser that is suppose to be supportive of internet standards (that was one of the original points, right?) these things need to be taken into consideration.
Comment 76 Rob Moss 2013-01-08 15:48:40 PST
In the three years since I first bumped up against this (and many others) issue my attitude has swung wildly from not caring to all-out rage. I've found some solace in accepting that if a UA stylesheet wants to override my CSS, it's quite within its rights to do so. So I write my CSS to appear "correct" to me, I test in IE, FF and Chrome, and if something looks wrong, I check for a bug, and if there's an open bug, I leave it looking broken in that browser. Most of these get resolved fairly quickly and the sites look okay again in all current major browser versions, but this one continues to persist.

I do however have a great deal of sympathy here. Fixing this is not at simple as removing !important from this rule. Is there any way we can alter this behaviour in a way that doesn't involve CSS? Or could we maybe have the -moz override rule suggested, or will that not work either?
Comment 77 John O'Nolan 2013-02-14 08:46:11 PST
Based on every other comment in this thread stating that the current behaviour is wrong + ridiculous, I believe that this additional comment of mine is entirely pointless. But, I comment nevertheless, in the naive hope that one day when critical mass is reached... perhaps in an alternate universe... logic and reason will prevail.

!important declarations should never exist in UA stylesheets.
Comment 78 Matt Giacomazzo 2013-05-28 17:00:00 PDT
At least give us an override rule because from this point forward I am giving preference to other browsers with my cross-browser fixes.

With IE9-10 I having to tweak my code less. Firefox with quirks like these risk losing more sentiment.
Comment 79 santiago.hollmann 2013-11-01 13:39:04 PDT
Guys, this is a really important problem when you want to customize your website.

We should figure out how we can say to Firefox that our !important declaration is more important than yours.

Thanks!
Comment 80 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2013-11-02 12:53:16 PDT
(In reply to Rob Moss from comment #76)
> I do however have a great deal of sympathy here. Fixing this is not at
> simple as removing !important from this rule. Is there any way we can alter
> this behaviour in a way that doesn't involve CSS? Or could we maybe have the
> -moz override rule suggested, or will that not work either?

Yes, there is a way this bug could be fixed, but as you said, it would require doing more than just removing the !important from forms.css.  The relevant code that would need to be modified lives in the file layout/forms/nsTextControlFrame.cpp in the https://hg.mozilla.org/mozilla-central/ repository.  I'd look particularly at the method nsTextControlFrame::Reflow and the things it calls.

To figure out what modifications you'd want to make, it's probably worth testing what other browsers do, since that behavior is likely to be compatible with Web content (whereas simply honoring small 'line-height' values and letting the text input shrink accordingly is, apparently, not).
Comment 81 Katrina 2013-11-26 14:36:17 PST
Today I am severely disappointed to come across this cross-browser compatibility issue and not only that but find that SEVEN YEARS have passed without this bug being fixed.
Comment 82 Katrina 2013-11-26 15:06:19 PST
Testing in all major browsers today reveals that only Firefox displays this undesirable behavior.
Comment 83 Archil Imnadze 2014-01-14 00:22:36 PST
Firefox breaks the specification here and I think it should be fixed as soon as possible.
Comment 84 Boris Zbarsky [:bz] 2014-01-14 06:31:51 PST
We actually don't break the specification, because these are replaced elements.

We all agree it would be nice to fix this.  The amount of work it would take is probably rather large, as you would know if you'd read the bug, because web sites depend on small line-heights not working.  So you can't just honor the line-height; you have to do something weird.
Comment 85 Mats Palmgren (vacation) 2014-01-28 14:44:25 PST
Created attachment 8366928 [details]
Testcase

You can change the "type" attribute value by clicking the "set type="
button and typing some value in the text field next to it.

AFAICT from testing Chrome33 on Linux and IE11 on Win7 is that they
allow line-height on <input type=text/password/number> only when
the effective value is larger than line-height:normal would be.

IE also allows line-height (unrestricted) on <input type=button/submit/
reset>.  Chrome appears to ignore line-height on those.

Both ignore line-height on type=file/checkbox/radio.
Comment 86 Mats Palmgren (vacation) 2014-01-28 14:52:49 PST
Created attachment 8366933 [details] [diff] [review]
wip

This seems to fix it for me.
https://tbpl.mozilla.org/?tree=Try&rev=e44811a9a570
Comment 87 thommson 2014-03-11 11:14:18 PDT
Sorry guys, this ist one of the most important render bug on this browser. All webdevelopers hate you for this! Why the you do NOT fix it?!?! SEVEN YEARS is a very long time...

ALL other browsers support this very good. FF was the best browser with the best CSS support a few years ago - but now it looks like we have to make extra css styles for FF? Really?? Kidding mee, feels like working on IE8 :(

Sorry but its still so terrible, and its seem the priority is not longer on quality more than on quantity.

regards
Comment 88 Archil Imnadze 2014-03-12 00:03:55 PDT
(In reply to thommson from comment #87)
> Sorry guys, this ist one of the most important render bug on this browser.
> All webdevelopers hate you for this! Why the you do NOT fix it?!?! SEVEN
> YEARS is a very long time...
> 
> ALL other browsers support this very good. FF was the best browser with the
> best CSS support a few years ago - but now it looks like we have to make
> extra css styles for FF? Really?? Kidding mee, feels like working on IE8 :(
> 
> Sorry but its still so terrible, and its seem the priority is not longer on
> quality more than on quantity.
> 
> regards

I agree. Should we fork Firefox and apply the updates?
Comment 89 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 01:33:44 PDT
Mats, did you want to get this landed?

(I think there was another bug where :bz was asking me about this same issue recently.)
Comment 90 x.redir 2014-03-12 02:05:13 PDT
An !important declaration should override another !important one. Not being able to override the default line-height on text inputs is pure stupidity.

It's been 8 years that this serious blocking bug has been reported and all we can see from the Firefox team is absolute laziness. It's like they have "mode: lazy !important;" and no matter how serious the bug is they won't get out of their lazy mode. Firefox is dead now. I'm not using it anymore, the dev team is just too slow to respond and react to find real-life solutions for real problems like this one...
Comment 91 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 02:10:45 PDT
That said, I think in the other bug I suggested putting the special-case in nsLineLayout::VerticalAlignLine.  I think it's actually needed in both places.

I also think it probably makes more sense to max() with 1.0 rather than the normal line-height, although it's worth checking the behavior of other browsers.
Comment 92 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 02:42:55 PDT
And yes, you're right -- we should get this fixed.  I'll try to make it happen for Firefox 30 or 31.
Comment 93 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 10:16:47 PDT
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #91)
> That said, I think in the other bug I suggested putting the special-case in
> nsLineLayout::VerticalAlignLine.  I think it's actually needed in both
> places.

... or actually maybe just one place:  nsHTMLReflowState::CalcLineHeight.
Comment 94 Robert 2014-03-12 11:43:58 PDT
I've been following this bug for quite some time, so it's nice to finally see some movement (again) on it. How likely is it that we'll have a way to directly impact line-height? Why/why not? It's a common direction in modern design to want to specify explicit heights for input and textarea fields, and have the cursor vertically center. As I said above, padding doesn't cut it because font spacing according to font size (the space in between padding) varies from browser to browser, where a line-height sets something explicit.

Is there a better method? In the years since I started following this bug, I haven't found a working alternative. Setting line-height (somehow, even w/ a -moz specific extension) is the preferred method.
Comment 95 Matt Giacomazzo 2014-03-12 12:18:44 PDT
There is really no way to override because the agent CSS uses !important. While using padding is less than ideal the third entry here http://css-tricks.com/snippets/css/css-hacks-targeting-firefox/ shows you how to target CSS only for Firefox so you can tweak just for that.

As someone who has been in electronic multimedia and the web space for about a decade I have to echo my concerns with such bugs taking years to fix. These and other features like quality image downscaling (https://bugzilla.mozilla.org/show_bug.cgi?id=486918 again years old here due to dependencies etc...), important for some RWD, are preventing users from experience the best of the web and we are having no choice to suggest Chrome over Firefox these days.

FF being an open source solution it is up to the community here to save it from falling behind. If anything is hindering the process of fixing these bugs I strongly suggest you organize and voice your concerns to Mozilla Foundation until they listen.
Comment 96 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 13:30:51 PDT
Created attachment 8390032 [details] [diff] [review]
patch 1:  Add an nsIContent* parameter to nsHTMLReflowState::CalcLineHeight
Comment 97 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 13:31:02 PDT
Created attachment 8390033 [details] [diff] [review]
patch 2:  Prevent html:input elements from having a line-height smaller than 1
Comment 98 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 13:31:11 PDT
Created attachment 8390034 [details] [diff] [review]
patch 3 - Allow pages to override line-height on form controls, except for <select>

This re-lands the part of the patch not backed out in
https://hg.mozilla.org/mozilla-central/rev/b97aef275b5e
Comment 99 x.redir 2014-03-12 13:51:20 PDT
(In reply to x.redir from comment #90)
> An !important declaration should override another !important one. Not being
> able to override the default line-height on text inputs is pure stupidity.
> 
> It's been 8 years that this serious blocking bug has been reported and all
> we can see from the Firefox team is absolute laziness. It's like they have
> "mode: lazy !important;" and no matter how serious the bug is they won't get
> out of their lazy mode. Firefox is dead now. I'm not using it anymore, the
> dev team is just too slow to respond and react to find real-life solutions
> for real problems like this one...


Why my comment was censored?
Comment 100 John O'Nolan 2014-03-12 13:55:52 PDT
I was wondering the same thing...
Comment 101 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 14:23:27 PDT
I've untagged the comments so they all show up again -- but I'd note that at this point all any additional comments are doing is making it harder for us to get the fix done.  I understand your frustration and apologize for not getting to this sooner, but more comments don't help.
Comment 102 Boris Zbarsky [:bz] 2014-03-12 14:27:14 PDT
Comment on attachment 8390032 [details] [diff] [review]
patch 1:  Add an nsIContent* parameter to nsHTMLReflowState::CalcLineHeight

r=me
Comment 103 Boris Zbarsky [:bz] 2014-03-12 14:30:08 PDT
Comment on attachment 8390033 [details] [diff] [review]
patch 2:  Prevent html:input elements from having a line-height smaller than 1

r=me
Comment 104 Boris Zbarsky [:bz] 2014-03-12 14:35:32 PDT
Not sure whether we want to restrict the clamp-to-1 behavior to text inputs (or other one-line-text-control inputs), though...  I _think_ for others it's OK to allow smaller values.
Comment 106 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 15:14:32 PDT
(In reply to Boris Zbarsky [:bz] from comment #104)
> Not sure whether we want to restrict the clamp-to-1 behavior to text inputs
> (or other one-line-text-control inputs), though...  I _think_ for others
> it's OK to allow smaller values.

Yeah.  I'll get this relaxation of the restriction landed, and then try relaxing more.



Try run here: https://tbpl.mozilla.org/?tree=Try&rev=7bbaebb73e51
Comment 107 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 20:35:54 PDT
Landed the above on mozilla-inbound:

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/e0e03efe760c
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/26b27dcceb73
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/58dc82ba5952
remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/a9182238dc0b

These changes, which still override values less than 1.0 to be 1.0, (unless they get backed out) be in:
 * the next nightly after they get merged to mozilla-central
 * Firefox 30

I still need to look into relaxing the restriction for input types other than single-line text inputs, so marking as leave-open.
Comment 108 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-12 20:39:52 PDT
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-7) from comment #107)
> I still need to look into relaxing the restriction for input types other
> than single-line text inputs, so marking as leave-open.

Actually, I'll do that in bug 697451.

This bug was about text-inputs, and it's pretty clear that we'd have compatibility problems if we let them shrink smaller than a line-height of 1.0.
Comment 110 Jean-Yves Perrier [:teoli] 2014-03-13 06:58:27 PDT
:dbaron, I've nominated this to be relnoted (old bug + useful for site design). As I'm a bit unclear with the real scope (the bug is quite difficult to read, with all the non-technical comments) of this specific bug, could you maybe propose a sentence describing the change (will be useful for Fx 30 for developers too :-) Thank you in advance!
Comment 111 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-16 23:01:36 PDT
(In reply to Jean-Yves Perrier [:teoli] from comment #110)
> :dbaron, I've nominated this to be relnoted (old bug + useful for site
> design). As I'm a bit unclear with the real scope (the bug is quite
> difficult to read, with all the non-technical comments) of this specific
> bug, could you maybe propose a sentence describing the change (will be
> useful for Fx 30 for developers too :-) Thank you in advance!

I'd cover both this and bug 697451 together:

 * the CSS 'line-height' property now affects single-line text inputs (input type=text/password/email/search/tel/url and unknown types) although it cannot shrink them below a line height of 1.0 (bug 349259)

 * the CSS 'line-height' property now also affects input type=button (with no restrictions) (bug 697451).

Putting it in Firefox 30 for developers sounds great.  (I'm not sure why it belongs in the release notes; I'm really not sure what the audience for the release notes is, or why some (?) of the content in Firefox N for developers also goes in the release notes.)
Comment 112 thommson 2014-03-17 15:24:16 PDT
You will make many people very happy!

A very big "Thank you"!
Comment 113 x.redir 2014-03-17 18:48:07 PDT
Indeed, after 8 years of waiting, this is quite welcome! During 8 entire years, Firefox was the only web browser to have this really annoying bug, neither of Opera (presto nor blink), IE6, IE7, IE8, IE9, IE10, IE11, Chrome and of course any derivative didn't have such annoying bug for such a long time.

Nevertheless I'm very happy that you're finally looking to actually solve bugs in Firefox! Having said that, what's the matter with the 1.0 limit for the minimum value? Can't you just FIX IT for good and for all? It's becoming really long! And what are we talking about? What is the unit of 1.0? 1px? 1%? what "1.0" means???? Please explain, and please please please PLEASE fix it too. 

Thanks so much for your work Mozilla guys.
Comment 114 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-17 18:51:27 PDT
The 1.0 means what line-height:1.0 always means.

And the reason for the restriction is that other browsers also don't make
  <input type="text" style="line-height: 0.1">
shrink to make most of the text hidden.  Since Web pages style inputs like this, dropping the 1.0 restriction would make text inputs on some major sites unusable.
Comment 115 x.redir 2014-03-17 18:56:37 PDT
Ok thanks for the explanation!
Comment 116 Matt Giacomazzo 2014-03-17 18:56:54 PDT
Curious to know if this is also an issue for <select>. It should also respond to line-height in the same way as text inputs since often their container and text alignment needs to match especially when they are placed inline with each other.
Comment 117 Boris Zbarsky [:bz] 2014-03-17 19:35:28 PDT
For <select> no browser allows changing its line-height, and the HTML spec currently forbids any styling of the insides of a <select> at all...  So changing the behavior there would need explicit spec changes, in addition to worries about compatibility issues and whether other browsers would be willing to make the change as well.  :(
Comment 118 John O'Nolan 2014-03-17 23:37:33 PDT
I don't think anyone expects Firefox to go against the spec - as long as the user is able to override the default rules with their own stylesheet.
Comment 119 Boris Zbarsky [:bz] 2014-03-17 23:44:02 PDT
I'm talking about https://www.w3.org/Bugs/Public/show_bug.cgi?id=25027#c2 which says (and looking at the spec it's correct, which is no surprise since Ian _wrote_ the spec) that the insides of a select are, per spec, not stylable period.  Not by the author, not by the user.  Not stylable.
Comment 120 John O'Nolan 2014-03-17 23:58:56 PDT
Which would be great, if all browser's selects behaved in the same way and provided a consistent experience to the end user. Unfortunately, though, they do not. Every vendor, OS and device applies its own quirks - so for the end user to have any hope of a consistent experience - web developers are left cleaning up your mess. You can try and paint the world into black and white as much as you want, unfortunately it's not very realistic.

You can make it easy for developers to clean up your mess (with CSS) or you can make it hard (we'll do it with JavaScript) - but either way it's going to happen, because the defaults you provide are simply not good enough. 

It saddens me the Firefox are willing to break the spec in all sorts of places when it's considered to be a an "exciting new feature" like video support or webfonts - going off down a rabbit hole with the justification that the experimentation and eventual adoption of the new technique is what the future spec will be based on.

And yet. When it's a simple issue like this - there's religious zealotry that the spec must be followed to the letter and should not contain any possible method of deviation. 

Just FYI, how it comes across to us lowly web developers: "When we deviate from the spec, we are right, deal with it" - and - "When we do not deviate from the spec, specs exist for a reason and we're only doing our job by following it.... deal with it"

It's an extremely disappointing attitude.
Comment 121 Boris Zbarsky [:bz] 2014-03-18 00:02:23 PDT
John, I'm personally interested in making <select> more stylable.  The issue is convincing other browser vendors to follow.  The spec is just documenting the behavior that every single browser implements.
Comment 122 Boris Zbarsky [:bz] 2014-03-18 00:05:10 PDT
And to be clear, we have proposed on numerous occasions making <select> more stylable.  Representatives from Apple, Google, and Microsoft opposed those proposals every single time.

So we're left with the options of either doing something totally different from every other browser (which gets web developers upset, and rightly so) or the other browser vendors changing their mind.  Please do feel free to convince them to do the latter.
Comment 123 John O'Nolan 2014-03-18 00:24:22 PDT
I'll get right on that. http://jsfiddle.net/9L7Fk/
Comment 124 John O'Nolan 2014-03-18 00:27:53 PDT
And to be clear, that was an example of "doing something totally different from every other browser"
Comment 125 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-18 02:24:43 PDT
Raising issues in resolved bug reports is an excellent way to ensure those issues are forgotten.  I'd suggest raising issues on selects in appropriate bug reports, and please keep one issue per bug report so that we can actually fix them.
Comment 126 x.redir 2014-03-18 02:37:37 PDT
> John, I'm personally interested in making <select> more stylable.  The issue is convincing other browser vendors to follow.

The first step in "convincing other browser vendors to follow" is to implement it on Firefox first, and then they will follow. Just like you follow most off-specs things that Google implement first (e.g. SPDY, etc.).

Cheers
Comment 127 x.redir 2014-03-18 02:39:06 PDT
(In reply to John O'Nolan from comment #123)
> I'll get right on that. http://jsfiddle.net/9L7Fk/

What is this supposed to showcase exactly? Chrome and IE11 render this MUCH BETTER than Firefox does!
Comment 128 John O'Nolan 2014-03-18 02:44:39 PDT
Yeah... that was kind of my point...
Comment 129 x.redir 2014-03-18 02:56:12 PDT
Oh I understand now, really well done then! Firefox is a mess in this demo!!! See screenshot comparison of Firefox/IE/Chrome: http://i.imgur.com/wyX0IoD.png

How come Firefox became the worse browser of all main 3, even IE can do better nowadays! Crazy!!! I recall the time I was recommending Firefox to friends/family, haaaa lost memories, this time is over! Firefox is near extinction, even if it is still used a lot, its extinction is near, just see how hard is it to even convince them that they can do better... All they can do is fight and argue on why their reasoning is better instead of getting to work and get things done!
Comment 130 John O'Nolan 2014-03-18 03:02:00 PDT
Nope. You lost me. Devolving to personal insults is not how to motivate anyone to do anything. It is up to us to prove that something is broken, not up to them to prove that it works. That is how software development works. We *should* be the ones doing the convincing.
Comment 131 x.redir 2014-03-18 03:08:54 PDT
Oky I'm sorry, you're right.

Nevertheless, it's still true that according to your jsfiddle, gecko is at present day the worse web browser engine, unfortunately. It's simple fact, no insulting here, this added to the single-process VS multi-process for Chrome and IE, I truly hope that Firefox will not die in the next couple of years.

Sincerely,
Gerard A.
Comment 132 Boris Zbarsky [:bz] 2014-03-18 06:27:56 PDT
> I'll get right on that. http://jsfiddle.net/9L7Fk/

That's bug 610733, as far as I can tell.  We should fix that, yes.  But that has nothing to do with line-height on <select>.
Comment 133 x.redir 2014-03-24 22:38:10 PDT
How come the status of this bug was switched to "RESOLVED FIXED" while the line-height is still completely buggy on <select> elements? It works great on all browsers (Chrome, IE, Opera, Safari) excepted Firefox, so there is nothing to convince other vendors here, they already do it right, Firefox is the last one to completely mess it up!

Please fix the line-height issue everywhere before marking this bug as fixed.
Comment 134 David Baron :dbaron: ⌚️UTC+2 (mostly busy through August 4; review requests must explain patch) 2014-03-24 22:57:04 PDT
There's a reason we don't have a single bug report in Bugzila that says "Mozilla has bugs", and leave it open until they're all fixed -- we want to discuss and track fixes to different bugs separately.  This bug was originally filed about text inputs, and we've fixed text inputs.  Fixing selects is a separate issue and won't be fixed in the same release as text inputs (since it's now too late to get other fixes in the release this fix is in).  Before changing the behavior of selects, I'd also like to have a chance to see and discuss tests showing the behavior of different browsers, all of which belongs in a separate bug report; this one is long enough and hard enough to follow already.  Please take that to bug 454625.
Comment 135 Boris Zbarsky [:bz] 2014-03-24 22:58:41 PDT
> while the line-height is still completely buggy on <select> elements?

Because this bug is about text inputs?

> It works great on all browsers (Chrome, IE, Opera, Safari)

Every single one of those browsers completely ignores line-height styles on <select>, as far as I can tell.  You can see this for yourself by loading <https://bug349259.bugzilla.mozilla.org/attachment.cgi?id=529629>.

If you have a testcase that shows any of those browsers doing anything with line-height on <select>, please file a new bug, attach a testcase showing them doing something, and cc me.
Comment 136 Boris Zbarsky [:bz] 2014-03-24 22:59:58 PDT
Or attach your testcase to bug 454625.  I'll needinfo you there.

Note You need to log in before you can comment on or make changes to this bug.