PX or REM in CSS? Just Use REM(austingil.com)
austingil.com
PX or REM in CSS? Just Use REM
https://austingil.com/px-or-rem-in-css/
72 comments
Isn't a lot of this somewhat moot with PX being a defined thing in browsers that isn't necessarily pixels? Per https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel
Completely irrelevant and MDN is infuriatingly “wrong.”
1px is not 1 physical pixel anywhere anymore. It’s just a “base unit” that we all agreed on decades ago. It could be 4 display pixels, it could be 9, it could be fractional if your monitor is downsampling it. It could be thousands if you zoom in. Heck, with PentTile matrix the pixel is never even “1 rgb pixel”
Also 1px is a digital unit and as such it does not have an “inch” equivalent, as much as designers like to insist that it does. Maybe it comes into play when you print pages, but even then the browser and the user can change the scale, so 1/96th of 1 inch is basically trivia at this point and should never be talked about in the context of “browsing the web”, even if it’s part of the CSS spec.
1px is not 1 physical pixel anywhere anymore. It’s just a “base unit” that we all agreed on decades ago. It could be 4 display pixels, it could be 9, it could be fractional if your monitor is downsampling it. It could be thousands if you zoom in. Heck, with PentTile matrix the pixel is never even “1 rgb pixel”
Also 1px is a digital unit and as such it does not have an “inch” equivalent, as much as designers like to insist that it does. Maybe it comes into play when you print pages, but even then the browser and the user can change the scale, so 1/96th of 1 inch is basically trivia at this point and should never be talked about in the context of “browsing the web”, even if it’s part of the CSS spec.
> 1px is not 1 physical pixel anywhere anymore
Nowhere did MDN make such a statement
> Also 1px is a digital unit and as such it does not have an “inch” equivalent
They're referring to the CSS "inch" (aka `in`). Which, similarly to the "pixel", has an arbitrary but well-defined meaning
Nowhere did MDN make such a statement
> Also 1px is a digital unit and as such it does not have an “inch” equivalent
They're referring to the CSS "inch" (aka `in`). Which, similarly to the "pixel", has an arbitrary but well-defined meaning
I feel like you are ultimately reinforcing the point? PX, especially in CSS, does not refer to a single device pixel. As such, it is just a smaller unit of measure, within all of the other units that are supported.
I grant that it is different from REM, in that it is not dependent on the root font-size. That said, I hesitate to see how that is a bad thing. Seems being stable between font changes is a good thing for most measurements on the page? I suppose it is a perspective of trying to make sure a set number of textual items fit in a space, or of keeping all of the boxes on the page the same size? I could see both being valid.
Edit: to be fair, my point on box sizes is made in the article.
I grant that it is different from REM, in that it is not dependent on the root font-size. That said, I hesitate to see how that is a bad thing. Seems being stable between font changes is a good thing for most measurements on the page? I suppose it is a perspective of trying to make sure a set number of textual items fit in a space, or of keeping all of the boxes on the page the same size? I could see both being valid.
Edit: to be fair, my point on box sizes is made in the article.
I'm not buying the font size argument at all. When you zoom in or out on a webpage, your base font size isn't changed, the whole page is zoomed instead, making this whole discussion moot. I would wager many (most?) nontechnical users don't even know they can change the base font size.
It's not zooming (ctrl +), it's when you literally set the font size in the browser. This is typically done for people with vision issues, or assistive technology
Something like 10% [EDIT: 3%? point remains] of people change their browser's default font size - a larger userbase than that of many browsers deemed worthy of support.
3% according to the first result I found, which sounds way more plausible.
https://css-tricks.com/users-do-change-font-size
I couldn't find stats on zoom but I'd guess far far more people use zoom than font size which makes sense because it works reliably and doesn't break site layouts.
https://css-tricks.com/users-do-change-font-size
I couldn't find stats on zoom but I'd guess far far more people use zoom than font size which makes sense because it works reliably and doesn't break site layouts.
It has been substantially below 2% in the tests I’ve done for various medium-sized business sites. We had to have serious discussions about the work involved to convert values between pixels and rems relative to the amount of people it serves. (Especially when browser-based scale zooms are totally sufficient)
Where is the disadvantage in supporting these 10% by using rem instead of px?
Sorry I wasn't clearer! Use of rem is preferable to px because it supports this cohort of users who change their default font size. Using px ignores their preferences. There are other benefits to adopting a typographic scale as the basis for truly responsive design. See https://every-layout.dev for a masterclass in exposition of this idea.
> There are other benefits to adopting a typographic scale as the basis for truly responsive design
Can you give some examples? I was of the belief that there weren't other benefits.
Nb I also dislike sources that use block and inline box model properties. It is a fictitious need: when will you ever add traditional Asian writing to your site?
Can you give some examples? I was of the belief that there weren't other benefits.
Nb I also dislike sources that use block and inline box model properties. It is a fictitious need: when will you ever add traditional Asian writing to your site?
Increased UI testing surface, tracing responsibility when things go wrong, and inserting a new decision for every single metric any FE developer ever writes.
- The more obscure combinations of viewing options you support, the more likely you'll miss some weird combination in your VRT or manual testing until an actual user in production finds it for you.
- But maybe your manual tester or VRT has excellent coverage. Still, it got more expensive. Supporting just one more text zoom level doubles your VRT expense. Your team has finite QA resources and VRT compute. Scope/quality/cost/time of something, somewhere, had to be dropped. Generally, is it worth it?
- If you are supporting REM and your designers don't distinguish between REM and PX, you have created new states that designers haven't planned for. You introduced a new cross-cutting source of design bugs, but if your designers didn't ask for this feature, they can't stem the flow of bugs!
- If you are supporting REM without coding guidelines to recommend what should be REM vs. what should be PX -- sans a hero dev who sees the impending mess and writes those docs for you -- you will get a chaotic and inconsistent mix of REMs and PX in your code.
- The more obscure combinations of viewing options you support, the more likely you'll miss some weird combination in your VRT or manual testing until an actual user in production finds it for you.
- But maybe your manual tester or VRT has excellent coverage. Still, it got more expensive. Supporting just one more text zoom level doubles your VRT expense. Your team has finite QA resources and VRT compute. Scope/quality/cost/time of something, somewhere, had to be dropped. Generally, is it worth it?
- If you are supporting REM and your designers don't distinguish between REM and PX, you have created new states that designers haven't planned for. You introduced a new cross-cutting source of design bugs, but if your designers didn't ask for this feature, they can't stem the flow of bugs!
- If you are supporting REM without coding guidelines to recommend what should be REM vs. what should be PX -- sans a hero dev who sees the impending mess and writes those docs for you -- you will get a chaotic and inconsistent mix of REMs and PX in your code.
Honest question: why do people increase the font size instead of just changing the default zoom level?
I feel that the latter creates a more consistent experience.
I feel that the latter creates a more consistent experience.
Depending on your vision, you might be able to see a button is a button, but the font is just too small by a few pts. You don't need borders or whatever zoomed, just the font size bumped a bit.
Maybe I want to keep seeing images at 1:1. Maybe the font sizes are bad. I remember the days when the user was supposed to be in control of how websites were styled.
Because they don’t want the layout to get bigger, but just the text size within the existing layout.
But then the articles recommendation doesn't make sense, because using rem for everything would also scale the layout.
I'd guess that you should always use pixels except for /(max-)?(width|height)/, because these are the only properties that may make assumptions about the size the content.
I'd guess that you should always use pixels except for /(max-)?(width|height)/, because these are the only properties that may make assumptions about the size the content.
Maybe because they just want bigger text and not a bigger site.
Because old web browsers didn't let people zoom properly. I think IE7 was one of the first.
Yeah, and that maybe makes sense in 2012, but not in 2022.
Exactly, zooming and base font size are two fundamentally different things. Forcing users to zoom to get a legible text size is not an acceptable solution.
Wouldn't users also want legible icons, pictures, margins, etc.?
It depends on the icons and pictures. With pixel-based graphics, you want to keep those 1:1 for crispness, and not get a blurry interpolation due to zooming, at least on lower-DPI screens.
Most pictures can be shrunk significantly and remain legible. They don't need to be zoomed in on.
No, not really. The browser setting is for default _font_ size for a reason. People want legible text. Design elements like icons, pictures, margins are generally decorative and not functional. If a user wants to set a default _zoom_ level, then they can set that as well. As I said, these are two different things.
Why not? If you have trouble reading text are you not also going to have trouble reading icons, pictures, etc. too?
It depends on the icons and pictures. With pixel-based graphics, you want to keep those 1:1 for crispness, and not get a blurry interpolation due to zooming, at least on lower-DPI screens. And the custom base font size may just be e.g. two pixels larger than the default for comfortable reading.
That seems like a very weak reason. High DPI screens are common now, as is SVG. And slightly blurry pixels is hardly the end of the world is it?
If that's the only problem I'll stick with px.
If that's the only problem I'll stick with px.
Low-DPI screens (e.g. Full-HD) are common on desktop systems and laptops, and will remain so for the foreseeable future, due to their lower cost, and due to native applications that aren’t designed for hi-DPI. Pixel-based icons look better on those than vector icons. “Slightly blurry” is the bane of modern visual UI design.
That's what the default zoom level is for. There are plenty of people who just need slightly larger text so they can read, but don't want to zoom in every element of the page. Why are you making assumptions about what users want instead of just supporting basic web browser defaults? It's really not that difficult to support.
The author's website sets a root font size of 18px. That completely eliminates any benefit you may have by using rems "for accessibility". Setting the root font size with an absolute unit completely overwrites the users' font size settings. Even the ones that the author mentions in the "The Real-real Problem" section. If you really want to change the root font size, you probably should use the `em` unit. It will be based on the users' settings.
Thanks for calling this out. I set that up a long time ago, but this gave me a good opportunity to fix it :)
If the solution actually was "just use REM" there'd be no point, as you could create a browser setting that does px->rem on all pages, as this is how the font is scaled in the first place.
This article is part of the problem; accessibility is not just a matter of ticking boxes with a "she'll be right" mentality so you can claim you support accessibility even though you're not doing it in a caring way that addresses users needs.
If you really care about accessibility you'll be using REM where it makes sense (fixing padding/margins that surround text), and not just by default like the article suggests.
This article is part of the problem; accessibility is not just a matter of ticking boxes with a "she'll be right" mentality so you can claim you support accessibility even though you're not doing it in a caring way that addresses users needs.
If you really care about accessibility you'll be using REM where it makes sense (fixing padding/margins that surround text), and not just by default like the article suggests.
I would like to make an inform opinion. Where could I learn more about the good practices on rem?
It’s odd how they seemed to know the difference between browser zoom and font size settings, but came to that conclusion
You should only use the unit that scales with the font size setting for font size related properties. That’s font-size, line-height, and letter spacing
You should only use the unit that scales with the font size setting for font size related properties. That’s font-size, line-height, and letter spacing
Yeah this. Directly scaling margin and padding with font size causes an accessibility _problem_ because the UI becomes unusable after a couple of steps, especially on mobile.
If every unit scales with font size then you’ve basically invented zoom, which browsers already have.
Dynamic Type on iOS is the perfect example. I have bad eyesight so I bump up the text size. This only affects the font size. It doesn’t scale the entire UI.
If every unit scales with font size then you’ve basically invented zoom, which browsers already have.
Dynamic Type on iOS is the perfect example. I have bad eyesight so I bump up the text size. This only affects the font size. It doesn’t scale the entire UI.
Yeah hard disagree.
Having fixed px values doesn't mean the page is less accessible. For sufficiently complex layouts you will always have to mix px, em, and rem.
Examples of things that should not scale with the root font size and usually set with px/em are layout elements like headers, footers, etc. as well as components like buttons, labels, icons, etc. Those should only scale with screen size so the page doesn't turn into an incomprehensible mess.
Having fixed px values doesn't mean the page is less accessible. For sufficiently complex layouts you will always have to mix px, em, and rem.
Examples of things that should not scale with the root font size and usually set with px/em are layout elements like headers, footers, etc. as well as components like buttons, labels, icons, etc. Those should only scale with screen size so the page doesn't turn into an incomprehensible mess.
> components like buttons, labels
... components like labels, which consist entirely of text, should not scale with the font size?
... components like labels, which consist entirely of text, should not scale with the font size?
Hard disagree. Those elements should all be easier to read when you scale the text size up. If your page can't scale without becoming an incomprehensible mess, then take it back to the design team.
Absolutely disagree. What is the point of scaling and accessibility, if I can't make your labels, buttons and footers readable?
I can't fix my sight, but you could adapt it so I'm not guessing.
I can't fix my sight, but you could adapt it so I'm not guessing.
The button text should get bigger if you increase the font size (obviously) but it doesn't always make sense to also scale the button's padding or shadow effect with the text, for example. As the text gets larger, most designs have to sacrifice space to make it work. Often this can be accomplished by fixing the size of pretty pixels that don't take away from usability.
It's only a way to help ensure the design scales. Otherwise it would be no different than zoom, as others have said.
It's only a way to help ensure the design scales. Otherwise it would be no different than zoom, as others have said.
Perhaps you're not used to accessibility?
There is a very vast chasm between zoom, and a responsive design that can scale to the base font size.
One can break context, and make it more difficult to follow the flow of content.
The other maintains context and flow, and is easier to interact with.
There is a very vast chasm between zoom, and a responsive design that can scale to the base font size.
One can break context, and make it more difficult to follow the flow of content.
The other maintains context and flow, and is easier to interact with.
https://www.joshwcomeau.com/css/surprising-truth-about-pixel... is a better breakdown, it's nuanced.
I'm still not buying the conclusion.
> In most cases, I think it makes more sense to use rems. This preserves the button's proportions, its aesthetics. And it reduces the risk of an overflow, if the button has a particularly long word.
Actually, the most appropriate technique, if you are more concerned with overflow and are ok with resizing the button, is just to set a min-width property and padding property.
This gives a consistent size for short-labelled buttons, and allows longer labels to seamlessly scale while achieving consistent padding.
If you would rather button size never change, then your constraint should take place at the label length, and you should specify a font-size.
In truth, user @jacobp100 is correct; it's best used as meant, which is solely for font-related properties.
> In most cases, I think it makes more sense to use rems. This preserves the button's proportions, its aesthetics. And it reduces the risk of an overflow, if the button has a particularly long word.
Actually, the most appropriate technique, if you are more concerned with overflow and are ok with resizing the button, is just to set a min-width property and padding property.
This gives a consistent size for short-labelled buttons, and allows longer labels to seamlessly scale while achieving consistent padding.
If you would rather button size never change, then your constraint should take place at the label length, and you should specify a font-size.
In truth, user @jacobp100 is correct; it's best used as meant, which is solely for font-related properties.
I've struggled with maintaining ad-hoc rules for REMs and PX. In my experience, designers very rarely specify units on metrics and assume PX all the way.
How do you feel about the coupling of "text-sized icons" to the size of text?
Does an icon next to a label make the icon's size font-related in your view?
My go-to heuristic lately is: "is this layout-related?" -> it gets the PX. "is this text-related?" gets REMs. Margins and padding are denoted "layout" -> PX.
How do you feel about the coupling of "text-sized icons" to the size of text?
Does an icon next to a label make the icon's size font-related in your view?
My go-to heuristic lately is: "is this layout-related?" -> it gets the PX. "is this text-related?" gets REMs. Margins and padding are denoted "layout" -> PX.
> How do you feel about the coupling of "text-sized icons" to the size of text?
You got me there. :)
This is one place where I break "convention", but only because I view icons as glyphs. So maybe the REM rule can be generalized to glyphs and not text. I typically just set icons to be 1rem. Any other size I typically specify in pixels however, as the coupling for me only makes sense as long as the glyph is glyph-sized.
> Does an icon next to a label make the icon's size font-related in your view?
Yeah, if it's an inline glyph. If the icon and label are vertically stacked however, I'm more inclined to use pixels.
You got me there. :)
This is one place where I break "convention", but only because I view icons as glyphs. So maybe the REM rule can be generalized to glyphs and not text. I typically just set icons to be 1rem. Any other size I typically specify in pixels however, as the coupling for me only makes sense as long as the glyph is glyph-sized.
> Does an icon next to a label make the icon's size font-related in your view?
Yeah, if it's an inline glyph. If the icon and label are vertically stacked however, I'm more inclined to use pixels.
I'd seen that article before, but I don't think I read the entire thing, and just now I noticed the trick about the CSS variables for approximate rem values, but in px. That's such a great idea!
I think this is pretty common knowledge anyway. It's rare to see anyone use px anymore, but I know for a fact the GitHub Blog does, and uses @media queries for mobile/desktop versions. Not sure what the reasoning is there.
I prefer to use REM, but I have experienced the following relatively frequently: large organizations in which the developers are somewhat uncomfortable with REM and as such use a converter function that turns your 1.2rem into an absolute pixel value as part of the build - surprisingly enough one place I worked at did this and also mandated that everyone should use rem which caused me to consider the expert they had consulting there that made this rule didn't actually understand the purpose of rem.
that said - rem with functions such as clamp, min, and max would seem to me to be problematic as it would be extremely difficult to understand all the potential effects it would have, since I think these functions, clamp especially are the most important for handling responsive displays I would probably drop the rem usage for anything but fonts.
Actually maybe even for fonts, if you increase the size of your base browser fonts from 16 to 18, it and h1 is specified as 1.5 rem it might be that the user wants most text on page - paragraphs etc. to be 18px but don't really want headings to be bigger than 24px. Also as clamp allows you to specify text size of an area fluidly based on container size this also seems to me as a better solution to most problems people will experience.
Unfortunately changing a single setting is too reductive to really help.
that said - rem with functions such as clamp, min, and max would seem to me to be problematic as it would be extremely difficult to understand all the potential effects it would have, since I think these functions, clamp especially are the most important for handling responsive displays I would probably drop the rem usage for anything but fonts.
Actually maybe even for fonts, if you increase the size of your base browser fonts from 16 to 18, it and h1 is specified as 1.5 rem it might be that the user wants most text on page - paragraphs etc. to be 18px but don't really want headings to be bigger than 24px. Also as clamp allows you to specify text size of an area fluidly based on container size this also seems to me as a better solution to most problems people will experience.
Unfortunately changing a single setting is too reductive to really help.
This is probably not for every website, but an interesting trick is to set your root element font size to 1vw, which is 1% the width of the viewport.
Then size everything using rems, including the width of your layout. The whole design scales with the width of your browser.
Then size everything using rems, including the width of your layout. The whole design scales with the width of your browser.
So if you have one of those ridiculous ultrawide monitors, the text is very large, or if you have a vertically-mounted monitor, are using a smartphone held vertically, or just prefer to make your browser windows narrow, the text becomes very small?
That sure is an interesting trick, all right.
That sure is an interesting trick, all right.
Can we use something like
font-size: "calc(min(1vw, 1vh))";
This might solve a few of the edge cases, but making the sizes of everything depend on your screen is a dumb idea. If I move my browser from my small laptop screen to my big external display, I expect to see more content, not larger fonts. My displays are set to scaling factors that are comfortable for me with most things I work with (HN’s tiny fonts being a notable exception). Just set a reasonable size for things (a base font size of 1rem should be fine) and let me use my displays to the fullest.
Ironically this is the least accessible solution because it doesn’t let the user change the font size at all (not that it’s particularly common in this day and age, due to full-page zooming being the default since at least 2010)
[deleted]
[deleted]
[deleted](1)
I don’t get it. I am semi visually impaired and often use command +/- to increase the font size, and on iPhone, use the reader viewer view for websites. Rems are terrible to use in CSS because they stack relative to their parent, making components non-portable and required hacks to undo parent sizing. Is default font size that prevalent that it’s worth the crappy units?
If you’re talking about the zoom controls in Safari (and any other modern browser), units are completely irrelevant. For the last 15 years, browsers have been changing the size of 1px rather than changing the root font-size. The whole viewport becomes “smaller” so it appears zoomed in.
> command +/-
This doesn't affect font-size (well, I guess you can set it up to do so in Firefox). There's a difference between increasing zoom and increasing font-size
This doesn't affect font-size (well, I guess you can set it up to do so in Firefox). There's a difference between increasing zoom and increasing font-size
[deleted]