
Why I dislike the rem unit (2013) - matthberg
https://vasilis.nl/nerd/dislike-rem-unit/
======
RobertRoberts
1\. Rem does not need a fallback [1]

2\. Rem works awesome for making default font sizing. (like a normalize in a
way) [2]

3\. Rem allows us to use a sort of centralized sorta relative sizing that
percentage and em just do not fulfill.

Rem is awesome, I think this guy just can't get passed the "it's new and so I
don't like it" problem.

[1] [https://caniuse.com/#search=rem](https://caniuse.com/#search=rem)

[2] [https://snook.ca/archives/html_and_css/font-size-with-
rem](https://snook.ca/archives/html_and_css/font-size-with-rem)

~~~
tln
> Rem is awesome, I think this guy just can't get passed the "it's new and so
> I don't like it" problem.

Maybe he has... the article is 7 years old, after all.

~~~
codazoda
I was about to chastise him for horizontal scrolling, but it's a personal blog
written years ago. Guess I can ease up. :P

------
zeroxfe
I think many of these don't apply today (bugs, fallback support, flexibility.)
My current project uses (almost) entirely rem and em units, and it is so much
cleaner and easier to manage than the alternatives.

------
gentleman11
This blog is written very pleasantly, but is giving advice about sizing units
while being two screens wide on my phone and having no right margin. Shrug

------
wildylion
Come on guys, I thought it was about radiation!

~~~
acidburnNSA
I was like, yeah and sieverts aren't much better! We need a more human
radiation unit. Like probably one based on multiples of average daily or
yearly background radiation doses from cosmic rays, radon, etc.

What's more useful? The tritiated water from Fukushima increases your
radiation by 0.6 uSv/yr!

vs. the tritiated water from Fukushima increases your radiation by 1/1000th of
your normal natural background dose!

------
philliphaydon
Wow. I dislike this blog. If you have a large resolution you get this thin
line down the right hand side of your screen.

~~~
wopian
and if you're on a mobile device you have to scroll horizontally to read the
paragraph

------
ravenstine
> Unfortunately rems are not supported on certain (older) browsers.

Poor argument, especially since IE9 supports them, and IE shouldn't be
supported anyway. I suppose people needed to back in 2013.

> With the rem unit we have a problem though. Since all font-sizes are
> relative to the root element, the font-size: 90%; rule is completely
> ignored. We now have to recalculate and override every font-declaration in
> the aside to get the same result. Spaghetti is wonderful as lunch or dinner,
> but not as code.

At this point, I question whether it's even necessary to use percentages for
font sizes deeper in the DOM than the root element. Unless the font is going
to change at any given viewport width, it's easier to just write the font
sizes for every screen breakpoint you have. I don't know why
developers/designers make things unnecessarily difficult. Most web designs
don't necessitate this kind of complexity.

> The rem unit is buggy

This was fixed years ago. Try it yourself in today's Chrome.

> Another reason why some people prefer rem over em is because inheritance is
> hard. I always tell these people they’re doing it wrong.

No they're not. They're using rem to properly support the user's right to set
the font size in their browser preferences and have it actually work on a
webpage. They're not using em because they probably don't need it. If they
didn't care about the user's font preferences, they'd probably use px because
it's easier for everyone to understand.

> The inheritance problem occurs when we nest a p in a li. The p will now be
> 1.2 × 1.2 = 14.4 pixels. This is too big. To make sure that a p in a li is
> 12 pixels too we now have to write extra, increasingly complex code:

So don't do that. Write your font sizes explicitly for each element, whether
it's px or rem.

Even better if you use a preprocessor like SCSS that supports variables and
mixins, which makes it even simpler to implement "flexible" font sizes without
the insanity of making font sizes in elements relative to other parent
elements. Even CSS variables that are now becoming ubiquitous help solve these
problems.

Despite those things, I still insist it's possible to avoid these headaches by
just not going the em route. They're rarely necessary.

------
paulgpetty
The age of the article says a lot; but I think there are overuses of rem, even
today, where it’s used for dimensions (width, height, padding, margins) which
is not a good idea. Especially when mixed with containing elements that use a
mix of em & px units. Where for a while sites were using em & rem, using
viewport-percentage lengths is more apprpriate for _both_ font-sizes and
dimensions.

And for what it’s worth Variable Fonts are a game changer that didn’t exist 7
years ago (along with a whole bunch of new standards and capabilities that
make typography and layout so different today), which makes me wish there was
a timeline view of all the W3C standards.

What’s interesting is that the blog for that article uses a theme with a lot
of that new stuff: css vars, flex box, margins & paddings with vh, calc, css
grid, font properties that probably aren’t widely supported — so @supports is
cool to see, and wait for … it:

max-width: calc(30rem * 2);

rem units

It looks like this is the Author’s own theme:

[https://vasilis.nl/nerd/wp-content/themes/nerd-
mississippi/s...](https://vasilis.nl/nerd/wp-content/themes/nerd-
mississippi/style.css?1558868656)

It seems like it had to have been updated since the article, so indeed maybe
he’s softened on rem, if not ...

Why use rem if you don’t like it & why use it for 2 max-width declarations?
There are a lot of % based dimensions so why not stick with that?

I’m not trying to judge, but the if the author created the theme for code
consistency and writing consistency that should get cleaned up.

There’s also some neat bleeding edg stuff like this:

h1 { font-family: "Mississippi Regular", impact, serif; font-weight: normal;
font-size: 15vw; font-size: calc(2em + 14vw); line-height: .7; margin: 0;
position: relative; font-size-adjust: .42; }

Where those two font-size declarations provide a responsive size where calc is
supported … But if you’re using @supports in some places that’s great to use
everywhere, for example he uses it here:

@supports (font-variant-ligatures: common-ligatures) { body { font-feature-
settings: normal; font-variant-ligatures: common-ligatures; } }

At some point font-variant-ligatures might be widely supported & using
something like postcss could let you purge or optimize that automatically & if
manually maintained rules like that just stick out do the road.

Rem is awesome, CSS can be painstakingly difficult to keep up with.

------
chrisseaton
How does sizing by pixel work when pixels are wildly different in size. As a
designer why do I want text to be half the size for someone on a high
resolution screen?

~~~
ravenstine
A pixel doesn't represent a hardware pixel.

[https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-
viva...](https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-viva-css-
reference-pixel/)

So knowing about the existence of the reference pixel, as someone who isn't a
designer, I don't see why text would have to be half size on a high resolution
screen. I've seen images targeted to pixel density, but fonts are vector so it
doesn't seem necessary. Am I missing something?

~~~
chrisseaton
Wow so a pixel is actually a unit of angle, defined from _inches_ of all
units!

~~~
flqn
Only the css reference pixel. In other contexts a pixel is a point sample with
no size

~~~
chrisseaton
> a pixel is a point sample with no size

They have pitches. When people talk about their size they mean the pitch.

------
chaorace
This guy sure does love Em-elia

