Move to REM units

[fynnfeldpausch]

There are numerous examples and articles out there discussing the advantages of REM units over PX units. Do you guys see a possibility to switch from PX to REM units at some point in the future?

[waterplea]

We never really looked into this since all our designs are in pixels :)

[fynnfeldpausch]

Would you be willing to give it a try if one provides PRs for it? Or is this a dead end?

[waterplea]

I think it would make it harder for us to follow the design specs for internal corporate projects. So I don't think so, unfortunately.

[fynnfeldpausch]

Ok, thanks for the clarification. One final idea - I could help extracting every px value to a SASS variable at the top of the file. This would help us to possibly use your framework by running a script to automatically convert them to rem units in a forked version and it could help you in the future to extract them to CSS properties (which I read you want to do).

[waterplea]

Hey @fynnfeldpausch

Do you have links to particularly convincing resources on REM? I'm thinking of dropping less variables and there's one that we use as a single measure of size in our design, which is 4px. I'm thinking we can drop it in favor of .25rem but I want to study this more since it's been a while I looked into the REM vs PX subject.

[waterplea]

What concerns me overall is that with moving everything to REM seems to have little benefits to locking the size in PX. It looks like it only matters when user changes default browser font size. And if we move everything to REM then it works, effectively, like browser zoom. I've managed to find following stats:

• a little over 3% of archive.org had their browser font size changed back in 2018
• none of alexa top sites respect this setting

I'll have some internal discussion with people who had positive experience using REM, if you have something to add - please do so :)

[WynieCronje]

I was busy logging a Feature. Then Realized I just wanted to be part of the Discussion.

View my thoughts below:

The idea is to get rid of All PX values (except for border thickness). And only use EM and REM.

EM
Inherits font size from parents, then scales accordingly.
1em = 100%.
0.8em = 80%

REM
Same as EM but gets font size from the root (Root EM).
The Default REM value is 16px. This makes the transformation quite easy from PX top REM

If value is 12px then rem is 12/16 = 0.75rem.

To assist with Calculations. I created variables in my project. No impact on designers, as I use font size as variables
(Should help with: I think it would make it harder for us to follow the design specs for internal corporate projects)

$16px = 1rem;
$15px = 0.9375rem;
$14px = 0.875rem;
$40px = 2.5rem;

And so on. Maybe we can introduce it in the root CSS variables?

Another thing to note. Sometimes components use elements with absolute positioning. Or sub text just slightly smaller than initial.
In these use cases we should be using EM .

This is cool, because now we can change the font size. And the entire app will scale accordingly. @waterplea Maybe this can be default for the corporate project? And allow user to change -> Save it in a cookie. Then user Feels in control.

I will be happy to assist with this 🥇

[fynnfeldpausch]

Can only agree with @WynieCronje. For us it becomes a basic requirement soon as we need to fulfill Web Content Accessibility Guidelines (WCAG). From my experience, the shift to REM is quite easy once you get used to it. To make life easier you can either create variables like @WynieCronje suggested or a simple function rem that does the conversion for a given pixel value (and is basically just a division by 16).

You should not reset the base font size of the browser because that defeats the entire idea of a11y. Instead, just assume a font size of 16px which is the default in all modern browsers by now.

The only thing that is a bit tricky is when it comes to compensating borders. You then just need to keep in mind that less arithmetics won't work and you need to use a CSS calc expression, e.g. calc(2.5rem - 1px);. But it works quite good. And having everything in REM makes scaling so much easier and accessible.

I found this a good read about the topic: https://www.24a11y.com/2019/pixels-vs-relative-units-in-css-why-its-still-a-big-deal/

Just as @WynieCronje, I will be happy to assist with this 🥇

[WynieCronje]

Another thing I used it for:

Scaling of components. I make the default font size for the component 1rem.

Then adjust the sizing ie:

.my-component
{
  font-size: 1rem;
  
  .size-sm {
     font-size: 0.8rem
  }
  
  .size-lg {
     font-size: 1.2rem
  }
  
    /*  
    ...
    everything inside uses em, to scale accordingly
    ....
    */
}

[waterplea]

I'm not talking about resetting it and dropping a11y/user preferences. I'm talking of setting 1rem to be 25% of default and then scaling everything from it. Like this:

:root {
  font-size: 25%;
}

body {
  font-size: 4rem;
}

So that 1rem is 1 unit of space per our design system. This would be an additional benefit for us to keep everything properly sized. Otherwise this doesn't seem like a big deal because if we remove PX in favor of REM we effectively make font scaling act the same as browser zoom, which is much easier to set up and configure for users and is much more often used.

I just read the article you linked and I do not see how REMs are more beneficial than PX in terms of zoom. Zoom works in all modern browsers scaling everything proportionally.

I was sent this article:
https://medium.com/hackernoon/rems-and-ems-and-why-you-probably-dont-need-them-664b9ce1e09f

While I don't like the way it is written it has a pretty good point:

• We know for sure that changing browser text size has no effect on facebook, youtube, amazon, twitter, medium, linkedIn, eBay, and I only got halfway down the Alexa top 100.
• So, we know for a fact that if someone can’t read 16px text, and they want to use one of those sites, they must use some other method.
• We also know that changing browser text size has no effect on the rest of the operating system, obviously.
• So again, we can deduce that if a user can’t read 16px text but wants to be able to read Excel menus, mail, system settings, finder/explorer, whatever else, they need to do that in some other way.

Browser font size doesn't even have effect on starting Chrome Google search page, other than one line of text. I'm going to have a discussion on Tuesday with another team to see what benefits REM can bring us. For now, I only see two:

1. We can imitate browser zoom through font size for those 3% who change it
2. We can simplify space unit of 4px by changing REM apparent value

Since we are a library we would need to somehow explicitly state the second point so apps who already use REMs will not have an unpleasant surprise. But at this point, without second argument REM benefits seem a bit superfluous. WCAG requirements are perfectly met by basic browser zoom which much more accessible to users.

[waterplea]

So I discussed it with a fellow team and they brought to our attention additional benefit of being able to slightly scale the whole app on various handheld devices. Say you have designed mobile app for iPhone SE with 320px width. Then on Pixel text and overall UI could look too small. With REM you can easily scale it depending on media queries. That sounds like a big benefit. And also it seems like changing apparent REM size to 4px might be confusing for people and make it harder to adopt Taiga UI so looks like we will not do it and keep it as is. I've created an issue to track this as a feature:
#154

[fynnfeldpausch]

Nice!