Skip to main content

CSS: em vs rem font sizes

 When do you use em and when do you use rem?


If you have ever asked this, you are like me :) So welcome.


Basically, to save you time here it is:

- If you want your font-size relative to the container's font-size, use em

- If you want your font-size relative to the 'root' (or html) element's font-size, use rem!


If you just stop reading now that might be sufficient, but if you are more curious, go on.

Example companion codepen: https://codepen.io/binodpanta/pen/RwLWRra

Basically your page should ideally always have a default font-size specified for the root, such as 


:root { font-size: 1em; }

This typically becomes 16px default for the base font size.

Now, if you use rems in your elements' styles you get a consistent scaling wrt this number! so if you do

div.someclass { font-size: 0.5rem; }

you are going to always get a nice scaled font size regardless of screen size. So all your fonts will scale relatively throughout the app! 

If you had used 0.5em, your calculated font-size could be 8px, but it could also be 1/2 of whatever the container's font-size was. And if that was itself em based, well.....

Isn't that nice?

In an upcoming post, I will also describe how it's not just font-sizes, but how em vs rem work with padding and margin. It's probably not what you think!


Comments

Popular posts from this blog

Unit testing code that uses environment variables and system properties with fakes

I did not exactly learn this today, but I am sharing it as I have found it extremely useful when unit testing code that depends on environment or system property settings. While I am using Java as an example, the general concepts apply any where. Problem : You have a piece of code you are unit testing that uses settings from env variables or system properties passed to the VM (System.getProperty), but you don't want the tests to be affected by the 'real' environment or system properties in the VM. So, your unit tests should not get different results or fail when the real environment changes. Solution : There are several. But the most straightforward is to use a mocking library to mock out the environment or fake it out, whatever your prefer. You can create a fake using a library like EasyMock, PowerMock etc. This I won't discuss in this post, since there are numerous articles for that. Or you can write a simple class that acts as a proxy, using the proxy pattern...

Using custom conditional logic to enable/disable Spring components

If you have a Spring component and you don't want it to load, you can use Spring's predefined conditionals as much as possible. For example, @Component   @ConditionalOnNotWebApplication   public class SchedulerEntryPoint implements ApplicationRunner { ...  } This will not load your component when running in non web application mode. Such as you may want to start the application but without any of the web framework using SpringApplicationBuilder. But sometimes you want to use custom conditions. It's pretty easy to do so, just use something like this @Component @Conditional (SchedulerCheck. class ) public class SchedulerEntryPoint implements ApplicationRunner { public static class SchedulerCheck implements Condition { @Override public boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata annotatedTypeMetadata) { return System. getProperty ( "scheduler" ) != ...

How to write and test Node.JS code that performs mutiple async tasks

This is currently WIP, I will fill in more details but it's a good starting version that is still hopefully useful to the reader... Recently I worked on a project that involved scheduling a number of tasks in parallel in Node.js. Running mutiple tasks I used the await-the library to do this. https://github.com/olono/await-the/blob/master/lib/result.js There are multiple ways to solve this kind of problem. Mainly you have to understand the Node.js is a single threaded environment (See Event loop) and how callbacks operate with a library like async or await-the. Basically, here idea was that you write a function that has a callback as its last argument ```   const doTask = async (arg1, callback) {    const results = await doStuffWith(arg1) ;    callback(results); } ``` Then perform this action on multiple inputs in parallel such as by using the excellent async.mapLimit function if you want to limit how many tasks in parallel you want to to...