1. Rem does not need a fallback [1]<p>2. Rem works awesome for making default font sizing. (like a normalize in a way) [2]<p>3. Rem allows us to use a sort of centralized sorta relative sizing that percentage and em just do not fulfill.<p>Rem is awesome, I think this guy just can't get passed the "it's new and so I don't like it" problem.<p>[1] <a href="https://caniuse.com/#search=rem" rel="nofollow">https://caniuse.com/#search=rem</a><p>[2] <a href="https://snook.ca/archives/html_and_css/font-size-with-rem" rel="nofollow">https://snook.ca/archives/html_and_css/font-size-with-rem</a>
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.
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
> Unfortunately rems are not supported on certain (older) browsers.<p>Poor argument, especially since IE9 supports them, and IE shouldn't be supported anyway. I suppose people needed to back in 2013.<p>> 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.<p>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.<p>> The rem unit is buggy<p>This was fixed years ago. Try it yourself in today's Chrome.<p>> Another reason why some people prefer rem over em is because inheritance is hard. I always tell these people they’re doing it wrong.<p>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.<p>> 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:<p>So don't do that. Write your font sizes explicitly for each element, whether it's px or rem.<p>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.<p>Despite those things, I still insist it's possible to avoid these headaches by just not going the em route. They're rarely necessary.
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.<p>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.<p>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:<p>max-width: calc(30rem * 2);<p>rem units<p>It looks like this is the Author’s own theme:<p><a href="https://vasilis.nl/nerd/wp-content/themes/nerd-mississippi/style.css?1558868656" rel="nofollow">https://vasilis.nl/nerd/wp-content/themes/nerd-mississippi/s...</a><p>It seems like it had to have been updated since the article, so indeed maybe he’s softened on rem, if not ...<p>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?<p>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.<p>There’s also some neat bleeding edg stuff like this:<p>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;
}<p>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:<p>@supports (font-variant-ligatures: common-ligatures) {
body {
font-feature-settings: normal;
font-variant-ligatures: common-ligatures;
}
}<p>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.<p>Rem is awesome, CSS can be painstakingly difficult to keep up with.
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?