Why I dislike the rem unit (2013)
vasilis.nl
vasilis.nl
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
[2] https://snook.ca/archives/html_and_css/font-size-with-rem
Maybe he has... the article is 7 years old, after all.
It's possible he's not maintained his site for some time.
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!
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.
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...
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.
[1] https://everymac.com/images/other_images/macbook-pro-retina-...
The actual density of pixels is physically fixed in the hardware.
https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-viva...
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?
They have pitches. When people talk about their size they mean the pitch.