.form-control height calculation inconsistent

[sts-ryan-holton]

Problem

Okay, I'm not sure how many people have noticed this behaviour with the .form-control regardless of input type. A decision was made in Bootstrap 4.1.3 to add a fixed height to the .form-control to compensate for differences in computed height across different types (see: https://github.com/twbs/bootstrap/issues/26867), however for me, in most cases the calculation appears to be slightly "off". It can be most identified with the Email Address field in the Forms component, see: https://getbootstrap.com/docs/4.1/components/forms/#overview

Reproduce

If you inspect the element and simply take off: height: calc(2.25rem + 2px); you'll see the placeholder text move slightly up and becoming more visually cantered (I picked up on this small thing :smile: )

Still can't see it? I've made a simple illustration (excuse the design skills here, I used paint.net)

A = current code and markup found on https://getbootstrap.com/docs/4.1/components/forms/#overview as discussed above.

B = I removed the height: calc(2.25rem + 2px); from my browser.

You'll see that in the first input (A) there is slightly more spacing between the red line that I've added compared to the top of the placeholder text that compared to B which is visually more centred.

Suggestions

I assume that this calculation has come from somewhere, however, I have consistently had this marginal problem on Macbook Safari, Chrome, Windows Chrome and Firefox. I was hoping of some SASS variable that I could edit to overwrite it in my code but couldn't find one. In fact, more often that not I find myself writing something like the following since 4.1.3:

.form-control {
  height: auto !important;
}

I'd also be curious to know who else is experiencing this and what can be done? :rocket:

[alainbelez]

this is more visible when you have an input-group-append after the input tag, see zoomed image below:

[sts-ryan-holton]

@alainbelez not entirely sure what will be done to fix the problem, but something I feel is causing more problems that it's worth, or at least a setting should be provided in the _variables.scss file to turn this on/off.

[mdo]

How much of this is still an issue after #27687 and #27663 were merged?

[sts-ryan-holton]

@mdo I can confirm that the behaviour that I've presented is still present in v4.2.1, simply follow: https://getbootstrap.com/docs/4.2/components/forms/ and remove height: calc(2.25rem + 2px); as shown in my description above, issue is still present for me.

Furthermore, I'm still having to keep the following on many of my sites:

.form-control {
  height: auto !important;
}

[MartijnCuppens]

Not sure how to continue with this one. Removing the height would reintroduce some alignment issues in other browsers and cause issues for <select> and some other input types like <input type="color">.

[sts-ryan-holton]

@MartijnCuppens Could this possible be a variable in _variables.scss which gives the option to remove, or remove by default and then the ability to re-enable

[Matthieu-Malyga]

I confirm that I have the exact same issue and that is visible with a button next to the input text box.

With the default setting :

With overwriting the height to auto :

[myplaneticket]

I am having the same issue, but the height: auto makes things misaligned in IE...

[dpw1]

@myorangeca so height: calc(2.25rem + 2px); should be applied uniquely for Internet Explorer, I believe. And all the other browsers use height: auto;. Correct?

[abstractic]

I honestly don't think there's much todo in this case, I was struggling with this issue today, because a client wanted to use a custom font. Then I realized that all fonts uses their own internal font metrics and formatting context, i.e. the baseline is not the same on any font.

Here's a very good article describing this issue http://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align.

I guess we need to tweak each indiviual case to fit the font that will be used. System fonts seems to be fairly correct in their baseline measurements, while others have a lot less padding at the bottom and therefore pushes down the baseline, so equal padding at the top and bottom of our input fields will not always make the baseline correct.

Maybe $input-padding-y-top and $input-padding-y-bottom could be needed.

[JayEnaR]

What works for me is to replace the .form-control with a custom width of 100% and wrap this in a div with a min-height.

[arborrow]

Using version 4.3.1, I was noting similar issues with height being calculated for a file type input. The issue is more obvious in FF than Chrome. In both cases, it looks better with height: auto.

Before (with default calculated height):

After (with height: auto):

I'm OK overriding the default behavior in my app but thought others might benefit from seeing what it looks like. My +1 for making the calculation only for IE but I am not an expert on such things so I defer to those who know best.

Peace - Anthony

[web-cooking-factory]

Hi,

I know this topic is old but I want to share what I've found out today.

I noticed a behaviour difference between Chrome and Firefox about the inner height (witouht padding) calculation of an element if you set a fixed or auto height.

This is my case: I have a font size of .825rem (13.2px) and a line-height of 1.5 for both inputs and buttons. So the inner height should be 13.2 * 1.5 = 19.8px. In Firefox, this height is the same if you set a fixed or an auto height for the element. But not in Chrome. If the height is fixed, the inner height is correct. But if the height is auto then the inner height is rounded down, 19px in my case.

In Bootstrap, the height of the inputs is fixed and the height of the buttons is auto. The calculation of the inputs height is logic, basically it's : $input-line-height 1em + ($input-padding-y 2) + ($input-border-width * 2). So that way, there shouldn't be any difference between setting this fixed height or auto.

The solution of setting height:auto on inputs works (but not by setting the $input-height variable as auto as long as it used by the custom file input for instance). But I've set another solution wich is:

`.btn{ min-height: $input-height;

&.btn-sm{ min-height: $input-height-sm; }

&.btn-lg{ min-height: $input-height-lg; } }`

It's useful only if you want to synchronize the inputs and buttons height and if the font-size, line-height, padding and border-width is the same for both.

It confirmed the problem comes from Chrome but I haven't found any topic about that, and also that there is no perfect solution but I think setting fixed height gives more control.

Bye !

[mdo]

This one is pretty stale and we've gone back and forth on these input heights. Per some of the old comments, I don't think we're going to make any changes here or variables for flipping heights off and on.