> Why use relative units? ... because today there are different assistive technologies so that users can modify the base styles of an application web among those the font size, using this type of relative units ensures that the elements are displayed correctly on all devices.
I'm not convinced by this. Afaik all browsers support font size increasing/decreasing even if you don't specify your sizes in em/rem.
Relative sizes can be useful for developers/designers when targeting different screen sizes, see also units like `vw` and `vh`. But that's not UX (user experience), just DX (developer experience).
You're assuming that font size increases in a browser are part of assistive technology and they are not. Relative font sizes are much more adaptable across a broad range of devices and technologies.
I gave this a test a few months back on some 40 popular websites and found only a few using relative units, and several had severe visual issues from changed base font sizes.
Browser zoom scaling seems to be the “much more adaptable” solution to me.
There are standard committees you can join if you want to share your opinion on how disabled people should be increasing their font size and having components run off page.
I think your sarcasm may have clouded the point you’re making :) I’m not sure what you’re getting at. Browser zoom generally does a much better job at overflow than font size scaling.
It's not quite the same. Firefox can change the default font size and Safari can set the minimum font size. If the rest of your layout has sizes set in pixels, then you will have 6 words in that "400px-wide container", whereas a "30em-wide container" would have fit that better.
In reality however no one cares about this anymore, at least since browsers have implemented full-page zoom and especially since responsive design became a thing, meaning that one should be able to zoom into a whole page and have it fit properly anyway.
So for me this is outdated information useful to about 3 users per website. Long gone are the days of 62.5% font size trick.
> Long gone are the days of 62.5% font size trick.
Isn't the 62.5% trick about making the code easier to write/understand/maintain? Or are you advocating for not using relative units at all? That might work for some use cases however it breaks if you need any kind of scaling feature within the site/app.
62.5% was specifically to bring the default 16px to 10px, which meant now 1em = 10px, at least at the root. With that, you could easily size your entire layout in EMs and, yes, keep it readable:
As far as i understand it's about `rem`, not `em` (which is relative to it's parent not the 62.5-normalized root element). And as long as you don't go all-in with absolute units (and loose all control over custom scaling on your site/app), you still need `rem`.
The 62.5 hack has been around for a decade before rem was even thought of. The fact that rem would be a better fit for it is irrelevant to the conversation.
I'm just saying that using em and rem for sizing isn't as useful as it once was.
My rule of thumb is to only use them for things directly related to text, like inline icons, text spacing and whatnot.
> Afaik all browsers support font size increasing/decreasing even if you don't specify your sizes in em/rem.
They do now, because zooming just couldn't be implemented properly in any other way since everyone was using px (I still remember the days of IE zooming some elements of a page and leaving the rest as they were). And because of that, everyone will just happily keep using px...
> I still remember the days of IE zooming some elements of a page and leaving the rest as they were
Sounds like you're referring to the proper text sizing that all browsers used to support, rather than the 'zoom everything' approach which is far less accessible. One of the biggest web downgrades we've seen, imo.
When you consider a single user reading a single website that might be DX. But if everyone needs to constantly tweak their font size in order every time they change websites, that is a UX problem.
> Afaik all browsers support font size increasing/decreasing even if you don't specify your sizes in em/rem.
Yes and no. On desktop you are right, however on mobile it is a whole different story. I'm visually impaired and I need font scaling in my OS and browser. That's why I can only use Chrome on Android and nothing else comes close on mobile.
In Chrome I can just set my preferred text size and most sites just adhere to this setting. Most of the time the only the odd element on a page glitches. Most of them are headings, which are often set in pixels. That's annoying, but no deal breaker.
Recently I tried switching to Firefox Mobile. In Firefox I can also set a preferred text size. But after some initial testing with my most visited sites, I came to the conclusion that Firefox Mobile is just poorly supported. Text sizes were all over the place. And it was unusable for me.
I also considered switching to iOS. But Safari doesn't even have a text scaling / sizing option. The only thing I could do on iOS is reader mode in Safari, but that's also site dependent. And I still have to pinch-zoom to set my text size every time I open a page.
And yes, I know I can pinch-zoom to enlarge all websites (except Google Amp!), but having to both horizontally and vertically scroll all text is extremely tiring.
iOS Safari does have a "Page zoom" setting that can be set per-site or as default in its settings, which is really mainly increasing the font size. It's probably not exactly as you like in Chrome.
I have tried this setting multiple times, but it doesn't do what I expect it to. I just tried it again on my wife's iPhone 12. I set the default page zoom to 200% and opened one of my regular sites (tweakers.net (Dutch)). When opening an article the content is zoomed in. When I pinch-zoom out the text size is small again.
On Chrome (Android) whenever I set the font size to 200% the behavior is more or less the same as on desktop. So the content is zoomed in and text sizes are huge. On iOS Safari Reader Mode works the way I expect to, but I find this a bit of a faff to use.
Thanks for this. I didn't know iOS had such an option. I've just tried this setting on my wife's iPhone and it enlarges text and elements quite significantly. However it still doesn't resolve my main issue with Safari.
On my Galaxy S21+ I use both a larger text size and zoomed in screen. Both are just basic sliders in the Display settings menu. Although not all apps or System UI elements adhere to these settings, unfortunately.
> I also considered switching to iOS. But Safari doesn't even have a text scaling / sizing option. The only thing I could do on iOS is reader mode in Safari, but that's also site dependent. And I still have to pinch-zoom to set my text size every time I open a page.
Apple basically invented the ability to dynamically resize browser text back in iOS 7 [1].
If you go to Settings > Accessibility > Display & Text Size and set Larger Text to On, you make the text as large as you like.
If you only want bigger text in iOS Safari, the popup menu allows you to resize the text on the fly.
> If you only want bigger text in iOS Safari, the popup menu allows you to resize the text on the fly.
Which also zooms in on the content, thus only letting me see part of the total width of the page. Which results in me having to both scroll horizontally and vertically.
Which also zooms in on the content, thus only letting me see part of the total width of the page. Which results in me having to both scroll horizontally and vertically.
Depends on the site; if they coded it correctly and met accessibility guidelines [1], it would support text sizing of 200% or more. Given the state of CSS today, it’s not difficult to make the text wrap within the viewpoint even at bigger sizes so you wouldn’t have to scroll.
So that the vertical rhythm can be maintained in relation to the typographic scale in use across differently sized text, and so that the browser font size settings are applied appropriately but so that neither they nor the degree of typographic scale in use (font size) affect the horizontal layout differently in different elements.
Of course, one might want to deviate from that rule as appropriate to build layouts that do partially respond to typographic scale horizontally, but in my experience, that is very rarely good-looking and tends to break layouts.
How does it make composing classes hard? Genuinely curious what the exact difficulty here is.
For the record, I don’t follow how the cascade applies in the context of an element declaring multiple CSS classes, as their precedence is defined by the order they first appear in CSS.
If the problem seems to be in how descendant elements’ classes compose the cascade, maybe the affected styles could be scoped less broadly?
Also, the @layer syntax seems to obviate this issue: simply define your typography on a different cascade layer separate from your container boxes and whatnot.
It comes in handy on large multi-brand enterprise sites where the same styles serve multiple domains. They are sharing layout but not necessarily the colors, dimensions, typography, iconography, or shape language.
It makes sense to systemically separate concerns in an environment like that, because it makes the same developers able to efficiently work on any of the sites; developers meaning one or more in-house teams, possibly with external consultants.
You usually want a line of text to have 60-80 characters. Given the fact some characters are thinner and some are wider than the ‘0’ character in a proportional font, making a paragraph 70ch wide gets you in the proper range.
> making a paragraph 70ch wide gets you in the proper range
It really does not. At 16px font size, Merriweather at 70ch renders >100 characters per line. Open Sans renders 88. Other fonts have even greater ranges.
Using ch values is worse than using absolute pixel values because it gives a false sense of correlation.
In practice, using a "ch" value for width is identical in behavior to just measuring out your intended width with absolute pixel values. Which is to say, neither of them accomplish the goal.
CSS doesn't have a unit that does, frankly... Content-oriented things are slowly coming, though. You can see that in properties like `line-clamp`. (I suspect that a unit that actually expresses characters-per-line is difficult at a performance level)
Also the vw/vh units are fundamentally broken, including viewport scrollbars, so that 100vw is wider than the viewport if there’s a vertical scrollbar and you’re on a platform where scrollbars take space (which is still most desktop platforms), thus triggering a horizontal scrollbar. Long ago the spec had a cumbersome and mildly imperfect solution for this, but only Firefox implemented it, and no one else wanted to so they eventually ripped it out of the spec and Firefox and left us with fundamentally broken units. Then they made new versions of the units to deal with the ways in which they were broken in ways that were a bit fiddly to deal with on mobile platforms, but completely ignored the way they were still completely broken on most desktop platforms. Sigh.
In short: viewport units are always wrong if you can have scrollbars, containing up to about 4% of error (though much more is theoretically possible). It is possible to use them safely, but the trouble is that most places where you actually want them can’t tolerate that error, so in practice they’re almost useless.
Here is another excellent breakdown by Joshua Comeau, who is my go-to for all things CSS-related. He goes over the practical cases where you do want to mix and match units, how browser zooming affects accessibility, etc.
Worth pointing out that the em is an ancient unit of measurement and represents the width of the letter ‘m’ in a given font, and rem stands for ‘relative em’ - as in relative to the body. I have always found this appreciation has helped my understanding.
em is an arbitrary font metric that actually has nothing to do with actual character measurements, and not even a particularly strong correlation. I measured the width/advance of m glyphs at font-size 16px in a handful of the fonts I have installed, and got values between 8.88 (Advocate, condensed) and 15.59 pixels (DejaVu Sans). The two monospaces I had were around 9.6. The regular serifs and sans-serifs were 12.01–15.59 with no obvious rhyme or reason. Some have different aspect ratios which lead to this, and some are just smaller or bigger than others at particular sizes by ten or even twenty percent. Font sizes are truly just fairly arbitrary numbers. (But there is the ch unit, which is actually based on font metrics: the width/advance of the 0 glyph. Also ex, the height of the x glyph.)
rem is root em, which for practical purposes means “not relative” in contrast to em, which is relative to the current or parent font size, depending on where you use it. (Sure, rem is still relative to the root font size in most places, and the initial font size in the root font-size declaration and in media queries, but it’s… less relative than em, if you will. Certainly thinking of it as “relative em” will lead you wildly astray.)
The default line height is defined by the font (and the browser may influence it in other ways too?), but it’s distinct from the em. (It’s easy to try in a browser. I see values like 18.78px and 19.33px and 21.67px on my 16px text.)
Since our designers use the language of pixels and we have the time to develop different breakpoints thoroughly, we tend to use that as well in our code. But I get a lot of value out of using ems in more local styles, in situations where I know the font size will be changing and I want certain things to scale with it.
One easy example is line-height on headings; font-size will change between breakpoints but you can usually pick a line-height so that you don't have to redefine that every time. Same with letter-spacing.
As to the accessibility concern - I've read it, but I've never been dinged on an audit for it. That's not some kind of conclusive non-happening because audits have problems of their own, but...I don't know, I guess I'd be interested in people talking about their experiences here, if they've had real-world situations where rems made things better for disabled users.
58 comments
[ 2.8 ms ] story [ 51.0 ms ] threadI'm not convinced by this. Afaik all browsers support font size increasing/decreasing even if you don't specify your sizes in em/rem.
Relative sizes can be useful for developers/designers when targeting different screen sizes, see also units like `vw` and `vh`. But that's not UX (user experience), just DX (developer experience).
Browser zoom scaling seems to be the “much more adaptable” solution to me.
In reality however no one cares about this anymore, at least since browsers have implemented full-page zoom and especially since responsive design became a thing, meaning that one should be able to zoom into a whole page and have it fit properly anyway.
So for me this is outdated information useful to about 3 users per website. Long gone are the days of 62.5% font size trick.
How many people do that in practice? Just a tiny subset of CSS enthusiasts.
Isn't the 62.5% trick about making the code easier to write/understand/maintain? Or are you advocating for not using relative units at all? That might work for some use cases however it breaks if you need any kind of scaling feature within the site/app.
I'm just saying that using em and rem for sizing isn't as useful as it once was.
My rule of thumb is to only use them for things directly related to text, like inline icons, text spacing and whatnot.
They do now, because zooming just couldn't be implemented properly in any other way since everyone was using px (I still remember the days of IE zooming some elements of a page and leaving the rest as they were). And because of that, everyone will just happily keep using px...
Sounds like you're referring to the proper text sizing that all browsers used to support, rather than the 'zoom everything' approach which is far less accessible. One of the biggest web downgrades we've seen, imo.
Yes and no. On desktop you are right, however on mobile it is a whole different story. I'm visually impaired and I need font scaling in my OS and browser. That's why I can only use Chrome on Android and nothing else comes close on mobile.
In Chrome I can just set my preferred text size and most sites just adhere to this setting. Most of the time the only the odd element on a page glitches. Most of them are headings, which are often set in pixels. That's annoying, but no deal breaker.
Recently I tried switching to Firefox Mobile. In Firefox I can also set a preferred text size. But after some initial testing with my most visited sites, I came to the conclusion that Firefox Mobile is just poorly supported. Text sizes were all over the place. And it was unusable for me.
I also considered switching to iOS. But Safari doesn't even have a text scaling / sizing option. The only thing I could do on iOS is reader mode in Safari, but that's also site dependent. And I still have to pinch-zoom to set my text size every time I open a page.
And yes, I know I can pinch-zoom to enlarge all websites (except Google Amp!), but having to both horizontally and vertically scroll all text is extremely tiring.
On Chrome (Android) whenever I set the font size to 200% the behavior is more or less the same as on desktop. So the content is zoomed in and text sizes are huge. On iOS Safari Reader Mode works the way I expect to, but I find this a bit of a faff to use.
Android has its own mechanisms: https://www.wikihow.com/Change-the-Screen-Resolution-on-Your...
Put another way, would it help to decrease the DPI rather than only adjusting text?
On my Galaxy S21+ I use both a larger text size and zoomed in screen. Both are just basic sliders in the Display settings menu. Although not all apps or System UI elements adhere to these settings, unfortunately.
Apple basically invented the ability to dynamically resize browser text back in iOS 7 [1].
If you go to Settings > Accessibility > Display & Text Size and set Larger Text to On, you make the text as large as you like.
If you only want bigger text in iOS Safari, the popup menu allows you to resize the text on the fly.
[1]: https://www.tpgi.com/text-resizing-web-pages-ios-using-dynam...
Which also zooms in on the content, thus only letting me see part of the total width of the page. Which results in me having to both scroll horizontally and vertically.
Depends on the site; if they coded it correctly and met accessibility guidelines [1], it would support text sizing of 200% or more. Given the state of CSS today, it’s not difficult to make the text wrap within the viewpoint even at bigger sizes so you wouldn’t have to scroll.
[1]: https://www.w3.org/WAI/WCAG21/quickref/?showtechniques=144#r...
I agree. But the cold, hard truth is that it just doesn't work.
- use px for borders, absolute positioning of small elements, etc. which you don’t want to scale at all
- use ch for setting text paragraph widths
- use rem for element horizontal padding/margin
- use em for everything else, like element vertical margin/padding, font and icon sizes
Of course, one might want to deviate from that rule as appropriate to build layouts that do partially respond to typographic scale horizontally, but in my experience, that is very rarely good-looking and tends to break layouts.
Set your typographic scale appropriately and learn to rely on the cascade instead of fighting it.
For the record, I don’t follow how the cascade applies in the context of an element declaring multiple CSS classes, as their precedence is defined by the order they first appear in CSS.
If the problem seems to be in how descendant elements’ classes compose the cascade, maybe the affected styles could be scoped less broadly?
Also, the @layer syntax seems to obviate this issue: simply define your typography on a different cascade layer separate from your container boxes and whatnot.
I like being able to increase the sizings of all elements inside a container just by increasing the element’s font-size.
It makes sense to systemically separate concerns in an environment like that, because it makes the same developers able to efficiently work on any of the sites; developers meaning one or more in-house teams, possibly with external consultants.
> use ch for setting text paragraph widths
I don’t know how much utility there is in estimating width with the size of the 0 character, unless you’re using a monospaced font.
It really does not. At 16px font size, Merriweather at 70ch renders >100 characters per line. Open Sans renders 88. Other fonts have even greater ranges.
Using ch values is worse than using absolute pixel values because it gives a false sense of correlation.
In practice, using a "ch" value for width is identical in behavior to just measuring out your intended width with absolute pixel values. Which is to say, neither of them accomplish the goal.
https://css-tricks.com/viewport-sized-typography/
- using vw/vh for font size / inline block sizing breaks zoom
- for the above reason, vw/vh is only useful for layout sizing, and there it is (almost?) always equal to % units
Is there a good use case for vw/vh not mentioned above?
In short: viewport units are always wrong if you can have scrollbars, containing up to about 4% of error (though much more is theoretically possible). It is possible to use them safely, but the trouble is that most places where you actually want them can’t tolerate that error, so in practice they’re almost useless.
https://www.joshwcomeau.com/css/surprising-truth-about-pixel...
https://www.w3.org/Style/Examples/007/units.en.html#future
em is an arbitrary font metric that actually has nothing to do with actual character measurements, and not even a particularly strong correlation. I measured the width/advance of m glyphs at font-size 16px in a handful of the fonts I have installed, and got values between 8.88 (Advocate, condensed) and 15.59 pixels (DejaVu Sans). The two monospaces I had were around 9.6. The regular serifs and sans-serifs were 12.01–15.59 with no obvious rhyme or reason. Some have different aspect ratios which lead to this, and some are just smaller or bigger than others at particular sizes by ten or even twenty percent. Font sizes are truly just fairly arbitrary numbers. (But there is the ch unit, which is actually based on font metrics: the width/advance of the 0 glyph. Also ex, the height of the x glyph.)
rem is root em, which for practical purposes means “not relative” in contrast to em, which is relative to the current or parent font size, depending on where you use it. (Sure, rem is still relative to the root font size in most places, and the initial font size in the root font-size declaration and in media queries, but it’s… less relative than em, if you will. Certainly thinking of it as “relative em” will lead you wildly astray.)
I didn't know about `ch` and `ex`, I'm gonna try them
One easy example is line-height on headings; font-size will change between breakpoints but you can usually pick a line-height so that you don't have to redefine that every time. Same with letter-spacing.
As to the accessibility concern - I've read it, but I've never been dinged on an audit for it. That's not some kind of conclusive non-happening because audits have problems of their own, but...I don't know, I guess I'd be interested in people talking about their experiences here, if they've had real-world situations where rems made things better for disabled users.