btn's height differs between different tags

[xavier83ar]

I know that this has been reported before, I've read all issues about this bug, but all of them are for 2.x and previous versions, and the newest bug reported is about 1 year's old.

However this bug is still present on bootstrap 3.0.1. I've made a test case to reproduce it, and a possible fix to it.

The issue

Here you can see the issue (screenshot)
https://www.dropbox.com/s/bns0wdl6cmzgmzr/Screenshot%20at%202013-11-04%2010%3A55%3A36.png

Here you can see the real test case:
https://dl.dropboxusercontent.com/u/1715488/bootstrap/btn-height-test.html

Bug fix proposal

I've removed vertical paddings. Instead, I've fixed button's height and line-height. It's been done inside of button-size(...) mixins, this is the result:

// Button sizes
// -------------------------
.button-size(@padding-vertical; @padding-horizontal; @font-size; @line-height; @border-radius) {
  @line-height-computed: floor(@font-size * @line-height); // ~20px
  // forzamos el height
  @btn-height: @line-height-computed + 2 * @padding-vertical + 2;

  padding: 0 @padding-horizontal;
  font-size: @font-size;
  line-height: @btn-height - 2;
  height: @btn-height;
  border-radius: @border-radius;
}

Screenshot:
https://www.dropbox.com/s/i8l0kj85xju315q/Screenshot%20at%202013-11-04%2011%3A07%3A09.png

Test case:
https://dl.dropboxusercontent.com/u/1715488/bootstrap/btn-height-fix.html

Notes

I've only tested in chrome, firefox and opera for linux, and only in desktops, but I've been using this method of "zero vertical paddings" for buttons since a few years with excelent results.
In fact I've been using bootstrap since 2.0 and I've always applied a patch to fix this (using this method) without any regressions or other issues, and I know that works ok in windows browsers, ios, and android browsers, but as I said I didn't make any serious test with them.

[cvrebert]

It's a known limitation/bug in Firefox; see the "Cross-browser rendering" box on http://getbootstrap.com/css/#buttons
We also don't officially support old Presto-based Opera at this point.

[zlatanvasovic]

This is classic problem in CSS. Browsers renders elements differenty and same class can differ between elements that use it.

A tip: Browsers renders elements differenty, but Chrome renders them the best. ;)

[zlatanvasovic]

Possible duplicate of #8700.

[xavier83ar]

I know that this is a known issue on firefox (and other browsers too), and that it is a common css problem rendering form elements, but if there is a solution that avoid those problems and differencies... I would at least try it.
I mean, what's the point of using tools like this, if it doesn't help to deal with browser's differences?, It's like if jquery's ajax function only work on some browsers and doesn't do it on others because of "browser implements ajax in a different way".

I mean, I think one of the main features of a ui css toolkit framework it's the cross browser consistency, I don't think that "the problem is firefox", or "it's opera" would be a good excuse.
And about Opera, for linux, presto based Opera is the latest version... but never mind, just to say, I know we are only a few :(

[zlatanvasovic]

@xavier83ar I have same thing as you, but this styling strategy (with height instead of vertical padding) isn't well known and isn't good for default version of any CSS toolkit. :(

[xavier83ar]

Oh, I didn't know. Do you know why? What's wrong with it? I don't mean that it's the best strategy, it just was something we (me and a designer friend) find and start using it 'cause we found it very usefull, but I've never read about that's was right or wrong...
I know that this approach is not good when you have text that wraps in more than one line, but in case of buttons (bootstrap buttons) have a rule to explicity avoid text wrapping, so I guess this is not that case.

[stephcurt]

Correct me if I am wrong, but lets look at the example on the http://getbootstrap.com/components/#input-groups-sizing page for the lg size.

The result is 1.33 on the line height and 10px on the padding. The span/input heights are both set to 45. If you actually do the math in this context, the height should be 45.9333px (as shows in the computed for the span) based on the line-height calculaton + 10px * 2 (vertical padding), the input element seems to floor the result to 45px, the span element is computing the actual result and then rounding up to 46 pixels.

I think we need to apply more logic to the line-height or the padding to ensure that the result ceilings or floors on the preprocessor level to make sure that the computed value will be the same on the css level, regardless of browser interpretation. Line-Height + Vertical Padding * 2 should equal a whole number value, which equals the height of the element.

This is my first comment on a git public project so please go easy if I am wrong here.

[stephcurt]

Sorry, line-height + padding + border

[stephcurt]

23.933 px on the line-height for the span vs 21 px on the line-height for the input

[stephcurt]

The font-size for both is 18. 18 * 1.33 is actually 23.933, not 21. In Chrome both compute as 23 (flooring).

[stephcurt]

So even if FireFox fixes their line-height calculation bug for input fields. why send over a number to the browser that can be interpreted ambiguously? Why not instead do the calculation is LESS and send over a whole pixel-number for line-height, and any other value that will end up rendering as a pixel?

[mdo]

For the time being, we won't be setting any height on buttons.

[stephcurt]

I'm confused, how does that address the issue?