PX or REM in CSS? Just Use REM
austingil.com
austingil.com
The term CSS pixel is synonymous with the CSS unit of absolute length px — which is normatively defined as being exactly 1/96th of 1 inch.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.
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 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.
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.
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?
- 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.
I feel that the latter creates a more consistent experience.
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.
REM for text, PX for layout
But if you're going to choose one, use rem with the body text-size hack.
If that's the only problem I'll stick with px.
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.
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
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.
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 labels, which consist entirely of text, should not scale with the font size?
I can't fix my sight, but you could adapt it so I'm not guessing.
It's only a way to help ensure the design scales. Otherwise it would be no different than zoom, as others have said.
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.
> 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.
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.
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.
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.
Then size everything using rems, including the width of your layout. The whole design scales with the width of your browser.
That sure is an interesting trick, all right.
font-size: "calc(min(1vw, 1vh))";
Or even dvmax in this day and age.
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