6 ms·

The real question is when to use which? - use px for borders, absolute positioning of small elements, etc. which you don’t want to scale at all - use ch for s

The real question is when to use which? - use px for borders, absolute positioning of small elements, etc. which you don’t want to scale at all - use ch for setting text paragraph widths - use rem for element horizontal padding/margin - use em for everything else, like element vertical margin/padding, font and icon sizes

klysm 4y ago
Isn't using em for font sizes almost always a bad idea? You get the compounding problem that way.
- eurasiantiger 4y ago
  You are only seeing it as a problem, because you do not understand the ”cascade” in Cascading Style Sheets. Set your typographic scale appropriately and learn to rely on the cascade instead of fighting it.
  - brianzelip 4y ago
    Hello `@layer`! https://developer.mozilla.org/en-US/docs/Web/CSS/@layer https://developer.mozilla.org/en-US/docs/Web/CSS/@layer
    - eurasiantiger 4y ago
      Oh great, more complexity. If only we could have good abstractions instead of mix’n’match utilities.
  - klysm 4y ago
    No I fully understand what is going on with cascading, it just makes composing classes hard. I use css variables for font sizes as multiples of rem.
    - eurasiantiger 4y ago
      How does it make composing classes hard? Genuinely curious what the exact difficulty here is. For the record, I don’t follow how the cascade applies in the context of an element declaring multiple CSS classes, as their precedence is defined by the order they first appear in CSS. If the problem seems to be in how descendant elements’ classes compose the cascade, maybe the affected styles could be scoped less broadly? Also, the @layer syntax seems to obviate this issue: simply define your typography on a different cascade layer separate from your container boxes and whatnot.
      - klysm 4y ago
        Yeah but why would you go through all that trouble when rem exists to solve this exact problem with font sizes.
        eurasiantiger 4y ago
        That’s not exactly true — using rem does solve the problem, but certainly that’s not explicitly the use case it was meant for. I like being able to increase the sizings of all elements inside a container just by increasing the element’s font-size.
        klysm 4y ago
        I guess there is a use case for that, but I've never wanted to do that.
        eurasiantiger 4y ago
        It comes in handy on large multi-brand enterprise sites where the same styles serve multiple domains. They are sharing layout but not necessarily the colors, dimensions, typography, iconography, or shape language. It makes sense to systemically separate concerns in an environment like that, because it makes the same developers able to efficiently work on any of the sites; developers meaning one or more in-house teams, possibly with external consultants.
wruza 4y ago
What idea is behind using root’s M height for horizontal spacing and a local one for vertical?
- eurasiantiger 4y ago
  So that the vertical rhythm can be maintained in relation to the typographic scale in use across differently sized text, and so that the browser font size settings are applied appropriately but so that neither they nor the degree of typographic scale in use (font size) affect the horizontal layout differently in different elements. Of course, one might want to deviate from that rule as appropriate to build layouts that do partially respond to typographic scale horizontally, but in my experience, that is very rarely good-looking and tends to break layouts.
  - wruza 4y ago
    Understood, thank you!
lelandfe 4y ago
rem for the stuff you want to scale by base font size. px for everything else. > use ch for setting text paragraph widths I don’t know how much utility there is in estimating width with the size of the 0 character, unless you’re using a monospaced font.
- alwillis 4y ago
  You usually want a line of text to have 60-80 characters. Given the fact some characters are thinner and some are wider than the ‘0’ character in a proportional font, making a paragraph 70ch wide gets you in the proper range.
  - lelandfe 4y ago
    > making a paragraph 70ch wide gets you in the proper range It really does not. At 16px font size, Merriweather at 70ch renders >100 characters per line. Open Sans renders 88. Other fonts have even greater ranges. Using ch values is worse than using absolute pixel values because it gives a false sense of correlation.
- eurasiantiger 4y ago
  User experience regarding content is more important than a pixel-perfect layout, which is a pipe dream anyway nowadays.
  - lelandfe 4y ago
    Sure, I understand the desire behind it. In practice, using a "ch" value for width is identical in behavior to just measuring out your intended width with absolute pixel values. Which is to say, neither of them accomplish the goal.
    - eurasiantiger 4y ago
      And what would accomplish the goal?
fragmede 4y ago
Don't forget about vw/vh; viewport width/height. https://css-tricks.com/viewport-sized-typography/ https://css-tricks.com/viewport-sized-typography/
- eurasiantiger 4y ago
  I intentionally left these out, as they are practically useless: - using vw/vh for font size / inline block sizing breaks zoom - for the above reason, vw/vh is only useful for layout sizing, and there it is (almost?) always equal to % units Is there a good use case for vw/vh not mentioned above?
  - chrismorgan 4y ago
    Also the vw/vh units are fundamentally broken, including viewport scrollbars, so that 100vw is wider than the viewport if there’s a vertical scrollbar and you’re on a platform where scrollbars take space (which is still most desktop platforms), thus triggering a horizontal scrollbar. Long ago the spec had a cumbersome and mildly imperfect solution for this, but only Firefox implemented it, and no one else wanted to so they eventually ripped it out of the spec and Firefox and left us with fundamentally broken units. Then they made new versions of the units to deal with the ways in which they were broken in ways that were a bit fiddly to deal with on mobile platforms, but completely ignored the way they were still completely broken on most desktop platforms. Sigh. In short: viewport units are always wrong if you can have scrollbars, containing up to about 4% of error (though much more is theoretically possible). It is possible to use them safely, but the trouble is that most places where you actually want them can’t tolerate that error, so in practice they’re almost useless.

klysm 4y ago

Isn't using em for font sizes almost always a bad idea? You get the compounding problem that way.

eurasiantiger 4y ago
You are only seeing it as a problem, because you do not understand the ”cascade” in Cascading Style Sheets. Set your typographic scale appropriately and learn to rely on the cascade instead of fighting it.
- brianzelip 4y ago
  Hello `@layer`! https://developer.mozilla.org/en-US/docs/Web/CSS/@layer https://developer.mozilla.org/en-US/docs/Web/CSS/@layer
  - eurasiantiger 4y ago
    Oh great, more complexity. If only we could have good abstractions instead of mix’n’match utilities.
- klysm 4y ago
  No I fully understand what is going on with cascading, it just makes composing classes hard. I use css variables for font sizes as multiples of rem.
  - eurasiantiger 4y ago
    How does it make composing classes hard? Genuinely curious what the exact difficulty here is. For the record, I don’t follow how the cascade applies in the context of an element declaring multiple CSS classes, as their precedence is defined by the order they first appear in CSS. If the problem seems to be in how descendant elements’ classes compose the cascade, maybe the affected styles could be scoped less broadly? Also, the @layer syntax seems to obviate this issue: simply define your typography on a different cascade layer separate from your container boxes and whatnot.
    - klysm 4y ago
      Yeah but why would you go through all that trouble when rem exists to solve this exact problem with font sizes.
      - eurasiantiger 4y ago
        That’s not exactly true — using rem does solve the problem, but certainly that’s not explicitly the use case it was meant for. I like being able to increase the sizings of all elements inside a container just by increasing the element’s font-size.
        klysm 4y ago
        I guess there is a use case for that, but I've never wanted to do that.
        eurasiantiger 4y ago
        It comes in handy on large multi-brand enterprise sites where the same styles serve multiple domains. They are sharing layout but not necessarily the colors, dimensions, typography, iconography, or shape language. It makes sense to systemically separate concerns in an environment like that, because it makes the same developers able to efficiently work on any of the sites; developers meaning one or more in-house teams, possibly with external consultants.

wruza 4y ago

What idea is behind using root’s M height for horizontal spacing and a local one for vertical?

eurasiantiger 4y ago
So that the vertical rhythm can be maintained in relation to the typographic scale in use across differently sized text, and so that the browser font size settings are applied appropriately but so that neither they nor the degree of typographic scale in use (font size) affect the horizontal layout differently in different elements. Of course, one might want to deviate from that rule as appropriate to build layouts that do partially respond to typographic scale horizontally, but in my experience, that is very rarely good-looking and tends to break layouts.
- wruza 4y ago
  Understood, thank you!

lelandfe 4y ago

rem for the stuff you want to scale by base font size. px for everything else. > use ch for setting text paragraph widths I don’t know how much utility there is in estimating width with the size of the 0 character, unless you’re using a monospaced font.

alwillis 4y ago
You usually want a line of text to have 60-80 characters. Given the fact some characters are thinner and some are wider than the ‘0’ character in a proportional font, making a paragraph 70ch wide gets you in the proper range.
- lelandfe 4y ago
  > making a paragraph 70ch wide gets you in the proper range It really does not. At 16px font size, Merriweather at 70ch renders >100 characters per line. Open Sans renders 88. Other fonts have even greater ranges. Using ch values is worse than using absolute pixel values because it gives a false sense of correlation.
eurasiantiger 4y ago
User experience regarding content is more important than a pixel-perfect layout, which is a pipe dream anyway nowadays.
- lelandfe 4y ago
  Sure, I understand the desire behind it. In practice, using a "ch" value for width is identical in behavior to just measuring out your intended width with absolute pixel values. Which is to say, neither of them accomplish the goal.
  - eurasiantiger 4y ago
    And what would accomplish the goal?

fragmede 4y ago

Don't forget about vw/vh; viewport width/height. https://css-tricks.com/viewport-sized-typography/ https://css-tricks.com/viewport-sized-typography/

eurasiantiger 4y ago
I intentionally left these out, as they are practically useless: - using vw/vh for font size / inline block sizing breaks zoom - for the above reason, vw/vh is only useful for layout sizing, and there it is (almost?) always equal to % units Is there a good use case for vw/vh not mentioned above?
- chrismorgan 4y ago
  Also the vw/vh units are fundamentally broken, including viewport scrollbars, so that 100vw is wider than the viewport if there’s a vertical scrollbar and you’re on a platform where scrollbars take space (which is still most desktop platforms), thus triggering a horizontal scrollbar. Long ago the spec had a cumbersome and mildly imperfect solution for this, but only Firefox implemented it, and no one else wanted to so they eventually ripped it out of the spec and Firefox and left us with fundamentally broken units. Then they made new versions of the units to deal with the ways in which they were broken in ways that were a bit fiddly to deal with on mobile platforms, but completely ignored the way they were still completely broken on most desktop platforms. Sigh. In short: viewport units are always wrong if you can have scrollbars, containing up to about 4% of error (though much more is theoretically possible). It is possible to use them safely, but the trouble is that most places where you actually want them can’t tolerate that error, so in practice they’re almost useless.