Good problem to solve, but this particular solution is a fast path to hell for everyone involved.
You just can't scale text size independently of layout and interface. The size of the text is fundamentally related to the structural layout of the page. The number of columns, the size of images, the relative placement of buttons and UI elements -- it's all inextricably tied to the size of the text.
Good news is that we already have a solution for this: responsive design, aka page zoom. Every serious site already gracefully handles a wide range of viewport widths. When you zoom in, you are simply simulating a narrower viewport width. This type of constraint and flexibility is already well tested. Zooming in makes the text bigger. And, zooming in makes the layout adapt to a single column when that's all that will fit. It all works harmoniously together, because we test and accommodate for all viewport sizes, which is the same as all zoom levels.
The proposal at hand to scale text alone is bad for everyone. Developers now have a geometric set of permutations to test. What about an ultra-wide viewport with large text? What about a small viewport with large text? What about a wide viewport with small text? It's so much that it won't make business sense to invest in all of the testing, and all of the design and implementation work to accommodate all of the cases. And so, it will be bad for end users who will set their text size to their preference, and then find that actually usability and readability are now worse.
In the end the answer is simple: when users set their text size to be larger in the OS, browser vendors should increase the default zoom in browsers. This is already how it works on Windows, and it is definitely the best path to happiness for all.
That's the testing matrix we have to do for iOS and Android apps today. The screen sizes don't go all the way up to ultrawide, but 13" iPad (portrait and landscape) down to 4" iPhone Mini, at every "Dynamic Type" display setting is required.
It's not that tough, but there can be tricky cases.
Browsers originally had text zoom -- only text zoom -- until page zoom was invented, I can't remember by which browser. And then page zoom quickly became the "main" zoom mechanism across all browsers because it was obviously so much better -- icons, layout, everything adjusted together. (And for those who remember, when there was only text zoom, it was a common practice/workaround to define everything in em rather than px, precisely to "fake" page zoom with text zoom.)
I'm baffled by the idea of trying to bring text zoom back. Just no, a million times. We tried it. It was bad.
Page zoom is fine for relatively minor adjustments, but if you're browsing with a high page zoom setting you'll still run into a ton of problems.
Stuff like "page overlays become so large that they overflow the bounds of the screen, but are fixed position so you can't even scroll them to make the X button visible."
Or in the slightly better case, "most of the screen is obscured by the enlarged floating header, the layout of which is totally broken by the relatively narrow viewport relative to content size, and with your large page zoom setting the remaining half of the screen can fit about five words on it at a time."
Either way websites need to do accessibility testing and clearly most of them don't.
Safari has a setting for "Never use font sizes smaller than __" which used in combination with a not as high page zoom setting is a little less likely to make pages completely fucked, because it's only acting on text that was small to begin with.
Oh, and there's TWO page zooms btw: the one you activate with +/- (or ctrl + +/-), and another one available with touchpad pitch-to-zoom / touchscreens (you can't use it on desktops without touchpad/touchscreen).
> how do we get large text to scale at a lower rate than body text. It's great that the body text can scale up from 16px to 32px, but does heading text need to scale up from 32px to 64px? It's already huge. If you have any thoughts, please do let me know!
Android 14 has this in non-linear text scaling -
> To prevent large text elements on screen from scaling too large, the system applies a nonlinear scaling curve.
I wish Android apps were better citizens when it comes to accessibility. My friend has very poor eyesight and I set his phone up to make things bigger for him, but most of the apps are a horrible janky mess of overlapping everything.
(Also "light mode" apps are painful for him to view, and most of the major apps have skipped out on offering dark mode)
Old timers remember that this was the old way of doing things, until at some point they changed to do full-page zooms, to the joy of developers.
Now they're adding support for this again, but `:root{font-size: 16px}` breaks it, so you're guaranteed to see that in CSS resets everywhere because there's nothing that managers hate more than inconsistencies
"QA user X mentioned that the text overflows when text zoom is at 300%. Fix it."
> "QA user X mentioned that the text overflows when text zoom is at 300%. Fix it."
We've adopted a stance that functionality trumps design at larger text scaling. Second, overflowing is preferable to truncating (also as per the WCAG, which says you shouldn't truncate / no information should be lost on larger text scales)
Yes, functionality trumps design if something has to give -- but what is the text overflowing into? Often it is overflowing into other text, and so now neither is readable. Or it is pushing other content unreachably outside the viewport. In this case, it's a lose-lose situation, in that both functionality and design have suffered.
> Text scaling doesn't need to replicate zoom. If you use font-relative units like em and rem everywhere that you set a length, everything will scale up the same way as browser zoom.
> Instead, only use font-relative units on things like text, images and icons. You don't need to use it on properties like margin, padding or gap.
> If you do that, there's more room for the content, which is especially important on portrait mobile devices.
So, for margin and padding, one should use px? Or is there a better unit?
After reading it, I'm still left asking why browsers can't do this for the user on mobile as well. User preferences should be respected by default and not require an opt-in step from the webmaster of all parties.
I tried using a bunch of zoom on my most frequented sites and they mostly worked just fine. At my day job everything is tested to work at 200% zoom as a baseline.
I really don't think we should bend over backwards to cater to accessibility offenders such as LinkedIn.
Most any site should work with zoom. This is about the scale of the text separate from the level of the zoom. The latter breaks a lot of sites because many common layouts assume the layout space for the text will always grow along with the text, as seen in zoom.
These days the vast majority of the (at least, English-speaking) web is only on a few dozen websites. The 80-20 rule would get you pretty far for most users' daily interactions.
> how do we get large text to scale at a lower rate than body text
Express the header text size with CSS calc function with a sum of em (relative) and px (absolute) values. Depending on their ratio, element will be more or less scalable. 100% em -> scales like body text, 100% px -> no scaling.
Readit News
You just can't scale text size independently of layout and interface. The size of the text is fundamentally related to the structural layout of the page. The number of columns, the size of images, the relative placement of buttons and UI elements -- it's all inextricably tied to the size of the text.
Good news is that we already have a solution for this: responsive design, aka page zoom. Every serious site already gracefully handles a wide range of viewport widths. When you zoom in, you are simply simulating a narrower viewport width. This type of constraint and flexibility is already well tested. Zooming in makes the text bigger. And, zooming in makes the layout adapt to a single column when that's all that will fit. It all works harmoniously together, because we test and accommodate for all viewport sizes, which is the same as all zoom levels.
The proposal at hand to scale text alone is bad for everyone. Developers now have a geometric set of permutations to test. What about an ultra-wide viewport with large text? What about a small viewport with large text? What about a wide viewport with small text? It's so much that it won't make business sense to invest in all of the testing, and all of the design and implementation work to accommodate all of the cases. And so, it will be bad for end users who will set their text size to their preference, and then find that actually usability and readability are now worse.
In the end the answer is simple: when users set their text size to be larger in the OS, browser vendors should increase the default zoom in browsers. This is already how it works on Windows, and it is definitely the best path to happiness for all.
It's not that tough, but there can be tricky cases.
And so I have it set to have smaller buttons but still a normal-size font.
Don't know about mobile, probably works there too.
Browsers originally had text zoom -- only text zoom -- until page zoom was invented, I can't remember by which browser. And then page zoom quickly became the "main" zoom mechanism across all browsers because it was obviously so much better -- icons, layout, everything adjusted together. (And for those who remember, when there was only text zoom, it was a common practice/workaround to define everything in em rather than px, precisely to "fake" page zoom with text zoom.)
I'm baffled by the idea of trying to bring text zoom back. Just no, a million times. We tried it. It was bad.
Stuff like "page overlays become so large that they overflow the bounds of the screen, but are fixed position so you can't even scroll them to make the X button visible."
Or in the slightly better case, "most of the screen is obscured by the enlarged floating header, the layout of which is totally broken by the relatively narrow viewport relative to content size, and with your large page zoom setting the remaining half of the screen can fit about five words on it at a time."
Either way websites need to do accessibility testing and clearly most of them don't.
Safari has a setting for "Never use font sizes smaller than __" which used in combination with a not as high page zoom setting is a little less likely to make pages completely fucked, because it's only acting on text that was small to begin with.
Actually Windows has a newish independent text scale accessibility setting that is different than display scale.
Yea, sometimes you have to update your UI to account for that, but it’s not a big deal most of the time.
https://learn.microsoft.com/en-us/windows/apps/develop/input...
... he writes, on a site that forces horizontal scrolling on mobile.
If I make HN font readable size on portrait phone using just zoom, the page is 4 screens wide.
Dead Comment
Android 14 has this in non-linear text scaling -
> To prevent large text elements on screen from scaling too large, the system applies a nonlinear scaling curve.
https://developer.android.com/about/versions/14/features#non...
(Also "light mode" apps are painful for him to view, and most of the major apps have skipped out on offering dark mode)
Old timers remember that this was the old way of doing things, until at some point they changed to do full-page zooms, to the joy of developers.
Now they're adding support for this again, but `:root{font-size: 16px}` breaks it, so you're guaranteed to see that in CSS resets everywhere because there's nothing that managers hate more than inconsistencies
"QA user X mentioned that the text overflows when text zoom is at 300%. Fix it."
We've adopted a stance that functionality trumps design at larger text scaling. Second, overflowing is preferable to truncating (also as per the WCAG, which says you shouldn't truncate / no information should be lost on larger text scales)
For example, NYT with 200% text-only scaling: https://i.imgur.com/zp7pDW3.png
So, for margin and padding, one should use px? Or is there a better unit?
I tried using a bunch of zoom on my most frequented sites and they mostly worked just fine. At my day job everything is tested to work at 200% zoom as a baseline.
I really don't think we should bend over backwards to cater to accessibility offenders such as LinkedIn.
Express the header text size with CSS calc function with a sum of em (relative) and px (absolute) values. Depending on their ratio, element will be more or less scalable. 100% em -> scales like body text, 100% px -> no scaling.