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.
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)
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?
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.
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.
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.
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.
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.
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.
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.
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.
