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

That seems to be intentional: see bug 82265 and bug 155483

This isn't really a duplicate of the bug that made this not work. This is, however, wontfix, per the discussion in that bug.

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.

> 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.

(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?

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....

(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.

> 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?

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.

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).

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.

Webkit has a minimum top padding of 1 pixel, unlike Presto and Trident.

Gecko puts 5 pixels above the text and chops off the bottom half of the text.

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.

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?

Ah, I thought your issue was with the padding, not the line-height. OK, then.

In that case I probably should have expressed myself better in the first place. :-)

Please just remove that '!important' part, that's all ! It's a quick fix, nope ? :)

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 :)

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?

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,

> 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...

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;".

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?

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.

See bug 82265 and the 9 bugs it blocks for the original set of testcases.

And note that that information is already present in comment 1 of this bug...

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.

+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.

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?

> they do in other browsers, even IE! Not quite. Do read bug 82265, please.

Actually scratch that. Comment 23 is the relevant thing here. I'll see about getting this into Firefox 6.

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 :)

I agree, thank you for doing it !! I'm at your disposal if you need testers later. Feel free to contact me.

David, what do you think of doing this after the April 12 branch?

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)

> 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 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.

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).

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.

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...

Actually, I was wrong. What Opera does is that it allows line-height to change unthemed <button> but not <input type="button">...

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.

Yay to that ! Thanks and congratulations ! :)

Note to self: need to fix test_animations.html as well.

Pushed http://hg.mozilla.org/mozilla-central/rev/e5668cb2a02f

Aaand, the first report of a site being broken due to this change. Youtube, to be precise.

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.

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).

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).

More precisely, I'm backing out everything except the <button> part. So we will effectively match Opera's behavior after that.

Did that in bug 658982.

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.

> 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?

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.

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.)

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...

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/

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.

For people who want to track <input type="button"> as opposed to text inputs, bug 697451 now covers it.

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.

Again coming up against this bug. It is ridiculous for a UA stylesheet to set !important declarations that cannot be overridden.

You can see that line-height work very well on Chrome and no effect on Firefox.

And what about <select> elements. I think the same thing applies there as well.

what about a -moz-min-line-height ? it would allow to reproduce the webkit behavior of not allowing line-height to be reduced.

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)?

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.

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.

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?

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.

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.

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!

(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).

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.

Testing in all major browsers today reveals that only Firefox displays this undesirable behavior.

Firefox breaks the specification here and I think it should be fixed as soon as possible.

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.

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.

This seems to fix it for me. https://tbpl.mozilla.org/?tree=Try&rev=e44811a9a570

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

(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?

Mats, did you want to get this landed? (I think there was another bug where :bz was asking me about this same issue recently.)

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...

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.

And yes, you're right -- we should get this fixed. I'll try to make it happen for Firefox 30 or 31.

(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.

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.

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.

This re-lands the part of the patch not backed out in https://hg.mozilla.org/mozilla-central/rev/b97aef275b5e

(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?

I was wondering the same thing...

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 on attachment 8390032 [details] [diff] [review] patch 1: Add an nsIContent* parameter to nsHTMLReflowState::CalcLineHeight r=me

Comment on attachment 8390033 [details] [diff] [review] patch 2: Prevent html:input elements from having a line-height smaller than 1 r=me

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.

I also filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=25026 and https://www.w3.org/Bugs/Public/show_bug.cgi?id=25027

(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

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.

(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.

https://hg.mozilla.org/mozilla-central/rev/e0e03efe760c https://hg.mozilla.org/mozilla-central/rev/26b27dcceb73 https://hg.mozilla.org/mozilla-central/rev/58dc82ba5952 https://hg.mozilla.org/mozilla-central/rev/a9182238dc0b

: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!

(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.)

You will make many people very happy! A very big "Thank you"!

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.

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.

Ok thanks for the explanation!

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.

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. :(

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.

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.

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.

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.

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.

I'll get right on that. http://jsfiddle.net/9L7Fk/

And to be clear, that was an example of "doing something totally different from every other browser"

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.

> 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

(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!

Yeah... that was kind of my point...

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!

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.

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.

> 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>.

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.

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.

> 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.

Or attach your testcase to bug 454625. I'll needinfo you there.