#1172: Other Spec Review: <meta name="text-scale" content="scale" />

Visit on Github

Opened Nov 24, 2025

Specification

https://drafts.csswg.org/css-fonts-5/#text-scale-meta

Explainer

https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/meta-text-scale.md

Links

The specification

Where and by whom is the work is being done?

Feedback so far

You should also know that...

No response

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1172

Discussions

Log in to see TAG-private discussions.

Discussed Dec 1, 2025 (See Github)

Matthew: I have not looked at this in detail yet, though I started to. The URL for the spec is someone's personal github account, but the explainer is in CSS WG. That makes sense.

Lola: we did discuss last week if anyone else wants to join Matthew on this issue. Please self-assign if you can. Let's ask in the Australia/Americas breakout too.

Matthew: great

Discussed Dec 8, 2025 (See Github)

Matthew: Thought this seemed pretty good. Haven't checked with the wider APA. This is one of the few things that's made me feel disabled on the web, that it doesn't reflect my chosen font size. If designers are faced with a situation where font sizes will change, designs will get more flexible and fluid.

Matthew: Good for them to scale font size keywords too, and they're planning that. They talked about having 2 modes: First do scaling linearly, so 2x font size can make some headings very huge. Second they might have a mode with non-linear scaling, with some way to specify that. Don't remember if they thought it should be under the author's control. But really it should be under the UA's control, since the user knows what works best. Don't know why it would need a separate keyword, since the UA can override it. The argument against the UA overriding this is that layouts aren't flexible enough, so they'll break. But this opt-in should be enough sign that the layout can cope with new sizes, including non-linear ones. So prefer 1 keyword. Might be ok for the author to also give some input, but UA should keep control. Kinda like when UAs all decided to ignore the maximum-scale keyword that disabled pinch-to-zoom. Let the UA control it. Think that's all compatible with their proposal. Would be ok if they still wanted 2 modes, but would encourage UAs to take a more active role.

Hadley: Big +1 to that, now that I'm more reliant on reading glasses.

Lola: Would this impact performance? Would someone with a custom font see a performance problem if user starts scaling?

Matthew: Don't think so. This says that sites can opt into the user's chosen base font size. On iOS or Android, you can say you want super-big fonts, and it does nothing on the web, which is wrong. Scaling will only happen once. Has a knock-on effect by adjusting the layout, which CSS can react to. No different from zooming in on desktop. Probably no performance impact. I also asked Serena for input. If nobody else has input, I should draft a comment for them.

Lola: Sounds good.

Discussed Dec 15, 2025 (See Github)

Matthew: Proposed a comment, what to people think?

(Reading the comment…)

Lola: Looks good, one suggestion: In your "from experience" part, where you give suggestions, could you give a suggestion that they get in touch with Docs CG? They could help with guidance for developers.

Comment by @matatk Dec 17, 2025 (See Github)

Hi @davidsgrogan, and thanks for your review request.

Speaking personally, as someone with a vision impairment, this is something I have wanted to see on the web for some time; thank you for working on it!

We have some feedback on the feature, the explainer, and concerns and suggestions about adoption.

Regarding the feature:

  • Overall, this seems like a great improvement.

  • Have you considered keeping only legacy and scale as values, and having the UA (on behalf of, and influenced by, the user, the device, and other factors) decide on what sort of scaling (linear or otherwise) to apply? This seems to be a decision on which the user would know best (possibly also guided by their UA and device).

    As you say in the explainer, the reason that text-scale has to be opt-in is potential breakage of existing sites. However, new sites that are designed with a more adaptive approach to text sizing could be much more robust against whether the scale is linear or otherwise.

    Have you considered explicitly making this choice up to the UA?

  • Regarding the question as to whether the font size keywords should also scale: we think this makes sense and should be included.

  • We'd agree in expecting it to be very likely there would be significant breakage of existing site layouts if scaling were the default. But out of curiosity: have you done any testing to check on this?

Regarding the explainer:

  • It's a well-written document, but it would be really helpful to have more illustrative examples - at least one "before and after" style example - of the effect of the proposal.

  • Our read on the proposal is that it would affect the base font size on desktop too (i.e. as well as mobile) - but the table makes this seem a little unclear - could you clarify?

Concerns regarding adoption:

From experience working with developers, the huge barrier this has to get over is that people need to opt in. It may be very hard to persuade busy development teams to opt in without some substantial resources to help them get started with such layouts. These may include:

  • Guidance for authors in the spec.

  • WAI Tutorials for authors to make more adaptive/robust/accessible layouts.

  • Making PRs on established projects such as

    • React Starter

    • Svelte

    • anything to do with bootstrapping projects

Getting this into the default <head> for projects will help achieve adoption - but it will also need some helpful resources for busy developers to ensure that the DX is still good.

You might want to contact Docs CG to see if they can assist you with writing the developer documentation.

We look forward to hearing your thoughts on this.

Thanks to @AutoSponge in APA WG for the benefit of his experience managing development.

Comment by @davidsgrogan Dec 17, 2025 (See Github)

Thanks for the great detailed review! Responses inline:

Hi @davidsgrogan, and thanks for your review request.

Speaking personally, as someone with a vision impairment, this is something I have wanted to see on the web for some time; thank you for working on it!

We have some feedback on the feature, the explainer, and concerns and suggestions about adoption.

Regarding the feature:

  • Overall, this seems like a great improvement.
  • Have you considered keeping only legacy and scale as values, and having the UA (on behalf of, and influenced by, the user, the device, and other factors) decide on what sort of scaling (linear or otherwise) to apply? This seems to be a decision on which the user would know best (possibly also guided by their UA and device).

Yes! The WG resolution and spec text about linear vs non-linear scaling does not require that a UA always do non-linear scaling (the spec draft has it as a SHOULD -- "user agents should scale these other keywords non-linearly to preserve readability"). I suppose you are suggesting that we expand that a bit to say that UAs should determine (based on the factors you list and maybe others) if linear vs non-linear scaling would be best. If that's what you mean, that seems good, I'll put it in the draft.

As for this part

Have you considered keeping only legacy and scale as values

Yeah, we decided to keep only those values. But we'll obviously consider any future author requests for other scaling modes.

As you say in the explainer, the reason that text-scale has to be opt-in is potential breakage of existing sites. However, new sites that are designed with a more adaptive approach to text sizing could be much more robust against whether the scale is linear or otherwise. Have you considered explicitly making this choice up to the UA?

We hadn't considered that. (Unless I've forgotten and @JoshTumath remembers.) But it seems like a great space for UA innovation -- to analyze if the page would scale appropriately even in the absence of an explicit text-scale. That would be great. (Let me know if I've understood that correctly.)

Agreed. To be clear other font size keywords will definitely scale. https://github.com/w3c/csswg-drafts/issues/12475 was about the further question of if they should scale linearly vs non-linearly.

  • We'd agree in expecting it to be very likely there would be significant breakage of existing site layouts if scaling were the default. But out of curiosity: have you done any testing to check on this?

Yes, but we unfortunately didn't document it. So, just now I did a test simulating default scaling at 1.7x and browsed around a bit. baltimoresun.com is a stereotypical example of breakage. The screenshot shows that the headlines and blurbs are cut off, which is bad enough, but much worse is that the user is even unable to horizontally scroll to see the cropped text. We found many examples like this, unfortunately.

<img width="300" alt="scaled baltimoresun homepage" src="https://github.com/user-attachments/assets/125d334e-aaf3-44b5-882f-3699c29d6c6a" />

Regarding the explainer:

  • It's a well-written document, but it would be really helpful to have more illustrative examples - at least one "before and after" style example - of the effect of the proposal.

1000% agreed. Will fix.

  • Our read on the proposal is that it would affect the base font size on desktop too (i.e. as well as mobile) - but the table makes this seem a little unclear - could you clarify?

Yes, it would affect base font size on desktop too. That's what we were trying to say with the "font-size: medium on desktop" row having "legacy: 16px × UA-level scale" vs "scale: 16px × OS-level scale × UA-level scale". (Suggestions for making that clearer are welcome. Perhaps we should explicitly say that font-size:medium is the base font size?)

Edit to add: though to be clear, this is a feature that we developed because of author feedback on mobile, and the mobile web will see the biggest usability improvements from this.

Concerns regarding adoption:

From experience working with developers, the huge barrier this has to get over is that people need to opt in. It may be very hard to persuade busy development teams to opt in without some substantial resources to help them get started with such layouts. These may include:

  • Guidance for authors in the spec.

  • WAI Tutorials for authors to make more adaptive/robust/accessible layouts.

  • Making PRs on established projects such as

    • React Starter
    • Svelte
    • anything to do with bootstrapping projects

Getting this into the default <head> for projects will help achieve adoption - but it will also need some helpful resources for busy developers to ensure that the DX is still good.

You might want to contact Docs CG to see if they can assist you with writing the developer documentation.

Yes, agreed. We are planning a bit of a PR push once the feature has shipped and stabilized for a few milestones. I see that https://www.w3.org/WAI/tips/developing/#write-code-that-adapts-to-the-users-technology is a candidate for where some instruction might live. We also have a few ideas for chrome's developer tooling to make this easier on authors, one of which we already implemented (simulating changing the OS text scale factor.) I'd considered pushing vscode to get this meta tag in their default HTML template, similar to meta viewport, but attacking it at the framework level also seems prudent. Thanks for the suggestion.

We look forward to hearing your thoughts on this.

Thanks to @AutoSponge in APA WG for the benefit of his experience managing development.

Comment by @JoshTumath Dec 19, 2025 (See Github)

As you say in the explainer, the reason that text-scale has to be opt-in is potential breakage of existing sites. However, new sites that are designed with a more adaptive approach to text sizing could be much more robust against whether the scale is linear or otherwise. Have you considered explicitly making this choice up to the UA?

We hadn't considered that. (Unless I've forgotten and @JoshTumath remembers.) But it seems like a great space for UA innovation -- to analyze if the page would scale appropriately even in the absence of an explicit text-scale. That would be great. (Let me know if I've understood that correctly.)

No we hadn't discussed that, but it sounds interesting. I'm sceptical about whether it's possible because of how unpredictable the existing text scaling is with text-size-adjust: auto; some areas of text grow while others don't and it's not clear to the author when it will happen. But if a UA is able to make that work, I'd be all for it!