14 ms·

PX or REM in CSS? Just Use REM

70 points by disadvantage 4y ago

T3RMINATED 4y ago
diob 4y ago
https://www.joshwcomeau.com/css/surprising-truth-about-pixels-and-accessibility/ https://www.joshwcomeau.com/css/surprising-truth-about-pixel... is a better breakdown, it's nuanced.
- soulofmischief 4y ago
  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.
  - martyfmelb 4y ago
    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.
    - soulofmischief 4y ago
      > 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.
- RheingoldRiver 4y ago
  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!
jacobp100 4y ago
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
- shortcake27 4y ago
  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.
skilled 4y ago
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.
_greim_ 4y ago
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.
- Cyberdog 4y ago
  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.
  - blumomo 4y ago
    Can we use something like font-size: "calc(min(1vw, 1vh))"; to solve problem you describe?
    - evan_ 4y ago
      In fact there’s a `vmin` unit that does this calculation for you. (`vmax` as well)
      - mikae1 4y ago
        > `vmax` as well Or even dvmax in this day and age.
    - Kwpolska 4y ago
      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.
Etheryte 4y ago
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.
- ehutch79 4y ago
  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
  - chrisweekly 4y ago
    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.
    - IshKebab 4y ago
      3% according to the first result I found, which sounds way more plausible. https://css-tricks.com/users-do-change-font-size 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.
    - croes 4y ago
      Where is the disadvantage in supporting these 10% by using rem instead of px?
      - chrisweekly 4y ago
        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 https://every-layout.dev for a masterclass in exposition of this idea.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
sublinear 4y ago
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.
- cosmotic 4y ago
  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.
  - sublinear 4y ago
    No that's what page zoom is for. When you change the text size in your browser... that's for text.
    - cosmotic 4y ago
      Almost all those things you listed include text.
- blep_ 4y ago
  > components like buttons, labels ... components like labels, which consist entirely of text, should not scale with the font size?
- shakna 4y ago
  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.
  - mrj 4y ago
    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.
uallo 4y ago
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.
- stegosource 4y ago
  Thanks for calling this out. I set that up a long time ago, but this gave me a good opportunity to fix it :)
taeric 4y ago
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 https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel 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.
- piskerpan 4y ago
  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.
  - culi 4y ago
    > 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
  - taeric 4y ago
    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.
stevebmark 4y ago
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?
- deleted 4y ago
  [deleted]
- p1318820 4y ago
  You're thinking of ems, not rems.
  - noduerme 4y ago
    ems have their uses, too! Especially for secondary/tertiary text where you might want it to always be 0.8 em of the parent but not want to write a whole separate set of media queries for it.
- piskerpan 4y ago
  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.
- culi 4y ago
  > 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
Vanit 4y ago
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.
- juanca 4y ago
  I would like to make an inform opinion. Where could I learn more about the good practices on rem?
deleted 4y ago
[deleted]
bryanrasmussen 4y ago
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.
deleted 4y ago
[deleted]

70 points by disadvantage 4y ago

diob 4y ago

https://www.joshwcomeau.com/css/surprising-truth-about-pixels-and-accessibility/ https://www.joshwcomeau.com/css/surprising-truth-about-pixel... is a better breakdown, it's nuanced.

soulofmischief 4y ago
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.
- martyfmelb 4y ago
  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.
  - soulofmischief 4y ago
    > 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.
RheingoldRiver 4y ago
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!

jacobp100 4y ago

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

shortcake27 4y ago
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.

skilled 4y ago

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.

_greim_ 4y ago

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.

Cyberdog 4y ago
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.
- blumomo 4y ago
  Can we use something like font-size: "calc(min(1vw, 1vh))"; to solve problem you describe?
  - evan_ 4y ago
    In fact there’s a `vmin` unit that does this calculation for you. (`vmax` as well)
    - mikae1 4y ago
      > `vmax` as well Or even dvmax in this day and age.
  - Kwpolska 4y ago
    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.

Etheryte 4y ago

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.

ehutch79 4y ago
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
- chrisweekly 4y ago
  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.
  - IshKebab 4y ago
    3% according to the first result I found, which sounds way more plausible. https://css-tricks.com/users-do-change-font-size 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.
  - croes 4y ago
    Where is the disadvantage in supporting these 10% by using rem instead of px?
    - chrisweekly 4y ago
      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 https://every-layout.dev for a masterclass in exposition of this idea.

deleted 4y ago

[deleted]

deleted 4y ago
[deleted]

sublinear 4y ago

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.

cosmotic 4y ago
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.
- sublinear 4y ago
  No that's what page zoom is for. When you change the text size in your browser... that's for text.
  - cosmotic 4y ago
    Almost all those things you listed include text.
blep_ 4y ago
> components like buttons, labels ... components like labels, which consist entirely of text, should not scale with the font size?
shakna 4y ago
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.
- mrj 4y ago
  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.

uallo 4y ago

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.

stegosource 4y ago
Thanks for calling this out. I set that up a long time ago, but this gave me a good opportunity to fix it :)

taeric 4y ago

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 https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel 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.

piskerpan 4y ago
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.
- culi 4y ago
  > 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
- taeric 4y ago
  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.

stevebmark 4y ago

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?

deleted 4y ago
[deleted]
p1318820 4y ago
You're thinking of ems, not rems.
- noduerme 4y ago
  ems have their uses, too! Especially for secondary/tertiary text where you might want it to always be 0.8 em of the parent but not want to write a whole separate set of media queries for it.
piskerpan 4y ago
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.
culi 4y ago
> 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

Vanit 4y ago

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.

juanca 4y ago
I would like to make an inform opinion. Where could I learn more about the good practices on rem?

deleted 4y ago

[deleted]

bryanrasmussen 4y ago

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.

deleted 4y ago

[deleted]