4 ms·

Try text scaling support in Chrome Canary

120 points by linolevan 9mo ago

socalgal2 9mo ago
As someone whose eyesight is getting worse, thank you for helping make this happen
pupppet 9mo ago
Why is this set as a meta tag rather than via CSS with html{text-scale:scale} for example?
- linolevan 9mo ago
  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.
- ameliaquining 9mo ago
  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/explainers/meta-text-scale.md https://github.com/w3c/csswg-drafts/blob/main/css-env-1/expl... [2] https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/env-preferred-text-scale.md https://github.com/w3c/csswg-drafts/blob/main/css-env-1/expl...
  - joshtumath 9mo ago
    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.
montroser 9mo ago
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.
- wetpaws 9mo ago
  [dead]
- dfabulich 9mo ago
  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.
  - mananaysiempre 9mo ago
ivanjermakov 9mo ago
Should have been tied to the window.devicePixelRatio instead of another input parameter that breaks the layout for some hidden reason.
- halapro 9mo ago
  How so? It's already related to `devicePixelRatio` and it's already handled by the browser as a full-page zoom.
londons_explore 9mo ago
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.
- SamBam 9mo ago
  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.
zamalek 9mo ago
I wish this could be met with universal approval, but this is quite a few fingerprinting bits to add to the bucket.
david422 9mo ago
> 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. https://developer.android.com/about/versions/14/features#non-linear-font-scaling https://developer.android.com/about/versions/14/features#non...
- qingcharles 9mo ago
  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)
fleebee 9mo ago
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.
- zamadatix 9mo ago
  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.
- ValdikSS 9mo ago
  They can, and they do. Opera does great zoom + text reflow since ≈2010 and counting.
kevin_thibedeau 9mo ago
What we need on mobile is the ability to pinch zoom on images to scale the page and pinch zoom on text with font scaling. This needs to work universally without depending on developers to include a CSS magic incantation. It's already ridiculous that a user agent will refuse to zoom at all because of the page design.
jlarocco 9mo ago
I dont' follow. The argument is that browsers can't respect a user's text size settings because LinkedIn has a terrible design that limits it to using less than 1/3 of the available screen space. Just one more reason I think the web is a dumpster fire, I guess.
- joshtumath 9mo ago
  Well that's just one example. Most websites have problems. Especially on mobile viewports.
zarzavat 9mo ago
This is a terrible idea. This meta tag will get copied and pasted by people who don't know what it means and the site will look just fine to the web developer, but whenever someone with larger text size tries to use the site it will be broken. In other words this is going to make things worse for exactly the group of people it purports to help.
avallach 9mo ago
> 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.
nextaccountic 9mo ago
> 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?
halapro 9mo ago
What's old is new again. 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."
- Cthulhu_ 9mo ago
  > "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)
  - halapro 9mo ago
    Explain that to the customer. Text looks different in my browser. Fix it. You can only push back so much
  - montroser 9mo ago
    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. For example, NYT with 200% text-only scaling: https://i.imgur.com/zp7pDW3.png https://i.imgur.com/zp7pDW3.png
    - yencabulator 9mo ago
      The problem there is trying to fit all the content on a single line. Obviously that's an immovable-object-vs-unstoppable-force scenario. Instead, let the layout elements flow downward.
feverzsj 9mo ago
Like web frontend dev isn't messy enough.
rawxtl 9mo ago
I didn't even realise it was a issue util now. Thinking about it, this should have been done years ago. never the less this is a great step forward and hope get's implemented soon.

120 points by linolevan 9mo ago

socalgal2 9mo ago

As someone whose eyesight is getting worse, thank you for helping make this happen

pupppet 9mo ago

Why is this set as a meta tag rather than via CSS with html{text-scale:scale} for example?

linolevan 9mo ago
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.
ameliaquining 9mo ago
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/explainers/meta-text-scale.md https://github.com/w3c/csswg-drafts/blob/main/css-env-1/expl... [2] https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/env-preferred-text-scale.md https://github.com/w3c/csswg-drafts/blob/main/css-env-1/expl...
- joshtumath 9mo ago
  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.

montroser 9mo ago

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.

wetpaws 9mo ago
[dead]
dfabulich 9mo ago
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.
- mananaysiempre 9mo ago

ivanjermakov 9mo ago

Should have been tied to the window.devicePixelRatio instead of another input parameter that breaks the layout for some hidden reason.

halapro 9mo ago
How so? It's already related to `devicePixelRatio` and it's already handled by the browser as a full-page zoom.

londons_explore 9mo ago

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.

SamBam 9mo ago
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.

zamalek 9mo ago

I wish this could be met with universal approval, but this is quite a few fingerprinting bits to add to the bucket.

david422 9mo ago

> 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. https://developer.android.com/about/versions/14/features#non-linear-font-scaling https://developer.android.com/about/versions/14/features#non...

qingcharles 9mo ago
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)

fleebee 9mo ago

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.

zamadatix 9mo ago
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.
ValdikSS 9mo ago
They can, and they do. Opera does great zoom + text reflow since ≈2010 and counting.

kevin_thibedeau 9mo ago

What we need on mobile is the ability to pinch zoom on images to scale the page and pinch zoom on text with font scaling. This needs to work universally without depending on developers to include a CSS magic incantation. It's already ridiculous that a user agent will refuse to zoom at all because of the page design.

jlarocco 9mo ago

I dont' follow. The argument is that browsers can't respect a user's text size settings because LinkedIn has a terrible design that limits it to using less than 1/3 of the available screen space. Just one more reason I think the web is a dumpster fire, I guess.

joshtumath 9mo ago
Well that's just one example. Most websites have problems. Especially on mobile viewports.

zarzavat 9mo ago

This is a terrible idea. This meta tag will get copied and pasted by people who don't know what it means and the site will look just fine to the web developer, but whenever someone with larger text size tries to use the site it will be broken. In other words this is going to make things worse for exactly the group of people it purports to help.

avallach 9mo ago

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

nextaccountic 9mo ago

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

halapro 9mo ago

What's old is new again. 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."

Cthulhu_ 9mo ago
> "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)
- halapro 9mo ago
  Explain that to the customer. Text looks different in my browser. Fix it. You can only push back so much
- montroser 9mo ago
  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. For example, NYT with 200% text-only scaling: https://i.imgur.com/zp7pDW3.png https://i.imgur.com/zp7pDW3.png
  - yencabulator 9mo ago
    The problem there is trying to fit all the content on a single line. Obviously that's an immovable-object-vs-unstoppable-force scenario. Instead, let the layout elements flow downward.

feverzsj 9mo ago

Like web frontend dev isn't messy enough.

rawxtl 9mo ago

I didn't even realise it was a issue util now. Thinking about it, this should have been done years ago. never the less this is a great step forward and hope get's implemented soon.