[HN Gopher] Try text scaling support in Chrome Canary
___________________________________________________________________
Try text scaling support in Chrome Canary
Author : linolevan
Score : 38 points
Date : 2026-01-27 19:20 UTC (3 hours ago)
(HTM) web link (www.joshtumath.uk)
(TXT) w3m dump (www.joshtumath.uk)
| socalgal2 wrote:
| As someone whose eyesight is getting worse, thank you for helping
| make this happen
| pupppet wrote:
| Why is this set as a meta tag rather than via CSS with html{text-
| scale:scale} for example?
| linolevan wrote:
| 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 wrote:
| 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...
| joshtumath wrote:
| 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 wrote:
| 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.
| dfabulich wrote:
| 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.
| ivanjermakov wrote:
| Should have been tied to the window.devicePixelRatio instead of
| another input parameter that breaks the layout for some hidden
| reason.
___________________________________________________________________
(page generated 2026-01-27 23:00 UTC)