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.
"The new CSS env(preferred-text-scale) variable provides a mechanism for authors to respect the user’s text scale setting that they’ve set either in their operating system or web browser settings. Authors can use it to scale the font-size and alter the layout accordingly.
Note: See the env(preferred-text-scale) Explainer [2] for a comparison of the various ways users can scale content and examples of how to use the environment variable.
However, if authors have already used font-relative units like rem and em to conform to the Resize Text guideline, the browser could automatically incorporate the OS-level text scale setting into those font-relative units. This would allow authors to avoid having to determine the precise elements to apply the env() variable to.
We propose a new HTML meta tag that tells the user agent to apply the scaling factor from env(preferred-text-scale) to the entire page. We expect it will become best practice for authors to use this meta tag, just as they would use the viewport meta tag. The environment variable would be reserved for atypical use cases."
There's no need for a text-scale CSS property because font-size already exists. The latter explainer [2] suggests that developers use font-size: calc(100% * env(preferred-text-scale)) to get the desired effect, if they are doing this in CSS rather than with just the meta tag.
Actually I don't think the explainer gets into the full story. The reality is it's not CSS's problem. It's the browsers that have historically made text scaling weird on each platform that they support.
And now just like with the viewport meta tag, we need a meta tag to say, 'Stop doing that please. Make the default font size in my CSS work the way it always should have'.
The other reason why the flag can't be in CSS is because it needs to make em and rem units in media queries get affected by the user's text scale. See the explainer for more info on that.
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.
This is supporting something that already exists for native phone apps. My phone has separate options for display size and text size.
And so I have it set to have smaller buttons but still a normal-size font.
In addition, desktop Firefox has had support for "zoom text only" for about 20 years or so (can be enabled in settings). It works fine.
Don't know about mobile, probably works there too.
Seriously.
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.
I wish this could be met with universal approval, but this is quite a few fingerprinting bits to add to the bucket.
I'm pretty sure this will only get supported by perhaps 5% of websites, making the feature effectively 'broken' for the user 95% of the time.
Should have been tied to the window.devicePixelRatio instead of another input parameter that breaks the layout for some hidden reason.
As someone whose eyesight is getting worse, thank you for helping make this happen
Why is this set as a meta tag rather than via CSS with html{text-scale:scale} for example?
The linked explainer [1] gets into this:
"The new CSS env(preferred-text-scale) variable provides a mechanism for authors to respect the user’s text scale setting that they’ve set either in their operating system or web browser settings. Authors can use it to scale the font-size and alter the layout accordingly.
Note: See the env(preferred-text-scale) Explainer [2] for a comparison of the various ways users can scale content and examples of how to use the environment variable.
However, if authors have already used font-relative units like rem and em to conform to the Resize Text guideline, the browser could automatically incorporate the OS-level text scale setting into those font-relative units. This would allow authors to avoid having to determine the precise elements to apply the env() variable to.
We propose a new HTML meta tag that tells the user agent to apply the scaling factor from env(preferred-text-scale) to the entire page. We expect it will become best practice for authors to use this meta tag, just as they would use the viewport meta tag. The environment variable would be reserved for atypical use cases."
There's no need for a text-scale CSS property because font-size already exists. The latter explainer [2] suggests that developers use font-size: calc(100% * env(preferred-text-scale)) to get the desired effect, if they are doing this in CSS rather than with just the meta tag.
[1] https://github.com/w3c/csswg-drafts/blob/main/css-env-1/expl... [2] https://github.com/w3c/csswg-drafts/blob/main/css-env-1/expl...
Actually I don't think the explainer gets into the full story. The reality is it's not CSS's problem. It's the browsers that have historically made text scaling weird on each platform that they support.
And now just like with the viewport meta tag, we need a meta tag to say, 'Stop doing that please. Make the default font size in my CSS work the way it always should have'.
The other reason why the flag can't be in CSS is because it needs to make em and rem units in media queries get affected by the user's text scale. See the explainer for more info on that.
Speculation on my part: Your site either supports accessible text scaling, or it doesn't. If only partly supports it – it might as well not at all.