Responsive Font Size

[farskid]

How do you make font sizes responsive and react properly to the viewport size and container? A better statement would be, where to use which font size unit?

[csswizardry]

My feeling is just to design for simplicity. If you make the right decisions and the right tradeoffs, you can get away with using the same typographic scale across all viewports. I’m not saying that you always should, but I am saying that you absolutely can (and it would keep designs and code a lot simpler if we were more strict with this).

However, my buddy Mike has done some pretty pioneering and impressive work with fluid type. I’d use this on any heavily typographical parts of your UI (e.g. blog posts). I’d be hesitant to apply this across the board.

A better statement would be, where to use which font size unit?

Never pixels. Never ems. Unitless line-heights (unless you need to align your text with something specific).

[farskid]

Thanks for the precise reply. Never pixels, Never ems, that means rem or % for font size?

[ruridge]

Never pixels is seems obvious, excluding 1px keylines I assume (or not?). What's the thinking behind Never ems? I assume you mean to use unitless values when the size should be a proportion of its parents font size. (Button padding for example). Along the right lines or am I totally off here?

[csswizardry]

Use rem for font-size (and for things like margin-bottom on typographic elements, to retain vertical rhythm through font-size changes).

Use pixels for almost everything like paddings on buttons, border-radii, etc. Pixels are immutable, easy to understand, and consistent.

Don’t use ems for anything other than media queries[1], because they’re mutable, they cascade, they inherit, and they’re difficult to understand (e.g. ‘1em here is 16px, but if I move it here it’s 24px. Wait, no, it’s 22px. Hang on, it’s 22px? I’m sure it should be 24px here. Oh no, it should be 20px here. Why is it 22px?!’)

Don’t go ahead and use rems everywhere because you’re probably over-engineering things if you do so. If your project manager or designer says to you ‘I would like the padding of this (button|calendar|modal|etc.) to change if we change the font size on the html element’, then use rems. Until that point, stick with pixels (simpler, immutable, etc.).

1. https://zellwk.com/blog/media-query-units/

[farskid]

@csswizardry Excellent. rem: Root element, typographic base font sizes, typographic base vertical margin em: Never ever. because of complexity and inconsistency, except media queries. pixels: For consistent and precise sizings such as button padding, ...

It looks such a nice attitude to put in styleguide. I totally agree with it and have suffered from em complexity enough.

[christian314159]

Don't want to start a war here, but I found ems to be an excellent solution for (independently) scalable components, give the base element a font size in rem, style everything else in em and you can use the same markup & css with one single override in two places on your site/app but in different sizes. Also great in A/B tests to see whether a component does better at a different size.

[farskid]

@christian314159 Something like this pen? http://codepen.io/farskid/pen/RpWOxO If yeah, it worked great for me. What would really be the best, the most scalable and the easiest method to maintain components, considering font size responsiveness in a production real world project?

[christian314159]

@farskid Yep, exactly. Nice example. If you are using a JS framework like React to render your UI, you could have a look into styled components or similar approaches of scoped CSS for better maintainability.

[tomhodgins]

Just as an add-on to the 'CSS Locks'-style fluid font sizing, when I want to use a scalable value with a minimum and maximum I use a little bit of JavaScript like this: http://codepen.io/tomhodgins/pen/ALWaVr

function clamp(min, mid, max) {
  return Math.min(Math.max(min, mid), max)
}

And then use that value in CSS. Here I use EQCSS to make use of that from within my CSS, but those looking for a vanilla CSS approach could have JavaScript update a CSS variable with the current value on load, resize, and other relevant events to keep this value constantly updated :D

[farskid]

@tomhodgins That seems like an additional effort!!! I like the idea that CSS issues be resolved only by CSS. That's why I propose vh, vw units.

[rbrtsmith]

@christian314159

have a look into styled components or similar approaches of scoped CSS for better maintainability.

I wouldn't say that CSS modules necessarily gives better maintainability. If your CSS isn't well architected then it can help solve problems.
However I don't yet see any significant improvements with these CSS in JS solutions over employing ITCSS and BEM(IT). Since employing these architectures / naming conventions I've never had an issue with specificity, naming collisions on dozens of projects ranging in scale.

@csswizardry regarding REM for other spacing units I find they can be quite easy to reason about if you employ a common spacing-unit This also allows things like grid spacing, list spacing and so on to also match the vertical (and horizontal ?) rhythm of the page, they can scale down slightly at breakpoints yielding more screen-real estate on smaller devices. I don't think it adds that much complexity. That last point of course is highly subjective 😄 I would be good to get your take. Might be worth taking a look at how I have done it on my Nebula repo