What is the Difference between px, rem and em?
carlmultimedia.com
carlmultimedia.com
https://www.joshwcomeau.com/css/surprising-truth-about-pixel...
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).
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.
.main {
width: 80em
}
.sidebar {
width: 20em;
}
.content {
width: 60em;
}
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.
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
- 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.
- 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.
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.