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?
But a CSS px isn't a physical pixel. In practice, it often used to be, because a CSS px was conceived in terms of typical desktop displays before the higher DPI monitors and mobile devices we use today were around. However, 1px in CSS often corresponds to a 2x2 or even 3x3 set of pixels on modern screens with their much higher physical pixel densities.
Pixels in CSS do mean something, which is very clearly defined and which does related in a natural way to what a physical pixel would have been at the time. It's just that the definition adapts in a useful way to modern equipment as well, so dimensions specified in px for older screens still look roughly the same on newer ones.
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?
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.
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!
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
That's too bad the "2013" label wasn't in the title when I commented. The blog's formatting is totally broken and I didn't notice any dates on his site.
It's possible he's not maintained his site for some time.
> 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.
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:
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:
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.
23 comments
[ 2.6 ms ] story [ 62.0 ms ] thread[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.
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!
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.
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.