Why use unitless line heights?

[nicoqh]

Re-opening this issue from the old repository:

Inuit calculates unitless line heights in order to place elements on a baseline.

Unitless line heights are usually advocated so that children don't inherit a calculated value from their parent. By using a unitless value (e.g. 1.5), a child will have a line height that is relative to its own font size and is therefore potentially different from its parent.

However, this is exactly what Inuit tries to avoid by calculating unitless line heights for every possible font size, all resulting in e.g. 1.5rem or a multiple thereof.

Why doesn't the inuit-font-size() mixin simply return (multiples of) $inuit-base-line-height in rems? Children would then inherit the correct calculated value and keep the vertical rhythm. Or have I missed something?

@csshugs pointed me to this article which states:

Unitless line heights are recommended due to the fact that child elements will inherit the raw number value, rather than the computed value. With this, child elements can compute their line heights based on their computed font size, rather than inheriting an arbitrary value from a parent that is more likely to need overriding.

As noted above, this "arbitrary value" is not arbitrary in inuitcss' case -- it's the value we actually want.

[herzinger]

Actually, you do make a strong case for using rem when sitting on a baseline grid. It's also a simpler calculation. The only issue I see is the need for a fallback for IE<9, in px (easy enough, but requires more output code) or unitless (which would mean we still need that same calculation AND more output code).

Knowing this, and keeping in mind that, when we do the correct calculation and set the value consistently as we do with the inuit-font-size() mixin, the end result is the same and requires no fallback, it kinda has no point in making the change, i guess.

[csshugs]

@herzinger Good answer! Nothing to add.

@nicoqh Does this answer your question?

[nicoqh]

It seems to me that unitless line heights were added because of convention, and that IE<9 support was a side effect. If other parts of inuitcss adds IE<9 support behind a flag that can easily be removed when support is eventually dropped, I'd vote for doing this consistently.

Also, rems result in the intended behavior when nesting font sizes, while line heights do not.

That is my opinion, but I recognize the reluctance to add more code and/or output. It is easy to pull in another implementation that addresses the baseline. :)

[csshugs]

@nicoqh

If other parts of inuitcss adds IE<9 support behind a flag that can easily be removed when support is eventually dropped, I'd vote for doing this consistently.

We removed the flag. Currently, every code always provides a fallback for IE<9.

Also, rems result in the intended behavior when nesting font sizes, while line heights do not.

Do you have an example?

[herzinger]

Also, rems result in the intended behavior when nesting font sizes, while line heights do not.

Your phrasing was a little odd, so I maybe I didn't get it right, but I think you are mixim it up. rem are relative to the document root's font-size, so it doesn't matter if it's nested or not. You may be thinking of em.

[anselmh]

Think of rem being a fixed value such as px, based on the root em value (meaning despite any set font-size on the element, a root em is used to calculate the value) and unitless line-height as equivalent to em (actually, they work the same), calculating the line-height relatively based on the current element’s font-size.

[nicoqh]

I'm aware, and this behavior was the reason for my suggestion :)

rem are relative to the document root's font-size, so it doesn't matter if it's nested or not.

With regards to my suggestion it matters because you can maintain the baseline without calculating unitless line heights for every child's font size.

Illustration: http://codepen.io/anon/pen/GjYGAa

However, you would need inuit-font-size() to calculate multiples of 1.6rem, as mentioned in the OP. If you want a font size of 3rems (larger than the baseline), you'd use a line height of 1.6rem * 2 = 3.2rem.

But @herzinger's point about IE8 may make it too cumbersome to implement, and it yields a bit more code. And as @csshugs pointed out, there are no IE<9 "flag" anymore, so my argument for keeping IE8 fallbacks inside the flag is mute :)