[css-env][css-fonts-5] New <meta text-scale> tag to make UA initial font size respond to OS text scale setting

@davidsgrogan

@davidsgrogan, @progers and I would like to propose a new HTML meta tag called text-scale with the following values:

<meta name="text-scale" content="legacy">
<meta name="text-scale" content="scale">

When the author specifies the scale option, the UA's initial font size is affected by the OS-level text scale setting.

➡️ For all of the details of the proposal, read our Explainer on a meta tag for text scaling behaviour.

We'd love to hear your feedback!

Background

In #10674, I wanted to solve the problem of how web content doesn't scale based on the OS text scale setting, which was an important accessibility issue for us at the BBC.

The CSSWG resolved to adopt:

a new environment variable env(preferred-text-scale), which will give authors the amount that the user has scaled their text size.
a new unit called pem which will be relative to env(preferred-text-scale)

Since then, we published an Explainer for env(preferred-text-scale).

However, after gathering feedback from authors at conferences recently, I found authors didn't like the sound of the pem unit. They would rather continue to use rem units as they do now. So we no longer believe the pem units are worthwhile, and believe the original idea for a <meta> tag to turn on the new/correct/proper text scaling behaviour will be much better (see the Explainer for more info).

Proposed resolutions

To adopt the proposal in the Explainer for a <meta text-scale> tag
To retract the resolution for a pem unit

I categorised this as relating to the css-env-1 and css-fonts-5 specs for now, but actually, if we all have consensus to adopt this, it's not clear to me what spec it would live in. It may even be in WHATWG territory.

To be a little clearer about the reasoning here (since the explainer just mentions the meta at the end as an alternative considered):

Before anything about this topic was introduced, the behavior was that text-size-adjust: auto applies heuristic size adjustment, upscaling some text to the UA/OS text size indicated by the user. Where this happens is unpredictable, as it's heuristic-based, and depends on the device being used (it only applied on mobile). Authors can't respond to this except by shutting down the auto-sizing altogether in a subtree, with text-size-adjust: none, and then hand-scaling their text by a page-chosen amount based on page-chosen device heuristics, with no way to know what the user wants. For back-compat reasons, we couldn't touch the initial font size of the page; text scaling is instead done as a funky used-value adjustment on individual elements.

We resolved on fixing this in two complementary ways: exposing the user's UA/OS preferred text scale factor in an env() value, and providing a pre-scaled pem unit which represents the page's initial font size, scaled by that scale factor. (The pem is just an authoring convenience; it's identical to calc(1rem * env(preferred-text-scale)) if the root's font-size wasn't adjusted.) Authors can then either set text-size-adjust: none and use the env()+pem to adjust things as needed by hand, or set text-size-adjust: calc(env(preferred-text-scale) * 100%) on the root to scale the entire page's text accordingly.

The new proposal complements this. The new <meta name="text-scale" content="scale"> value bakes the UA/OS text size adjustment into the page's initial font size (aka font-size: medium on the root), makes text-size-adjust:auto behave identically to none (because there's no need to scale), and sets env(preferred-text-scale) is 1 (ditto). Authors don't need to do anything further; it's identical to the "force text-size-adjust to match the env(preferred-text-scale)" solution from above, but easier to use.

We also think that, with this, we can probably drop the pem unit, since it's subsumed by just using rem + the meta value. We still want to keep the env(), as there are some use-cases that do want to respond to the user's preferred text scale in a more case-by-case basis, and they can continue using just using text-size-adjust: none and either omitting the meta or setting it to the legacy value, then using the env() where desired.

In general I hate these <meta> things, but I think for this use case it makes sense, and I agree 100% that letting rem units behave as intended is a better author experience. Some things to think about:

Use compat or fixed and user or adjustable as the keyword values for the <meta>? Since that better reflects that the initial value is fixed at 16px for compat, and the new value is intended to match user adjustments.
Remap the other absolute size keywords appropriately so that they also scale with medium.
Consider remapping the other absolute font-size keywords in a way that reflects the OS text scale, which IIRC doesn't always scale linearly with the body text size.
Maybe also allow these keywords in calc() etc. so that authors can interpolate those sizes, too?
Recommend to authoring tools that they offer simulation of various size preference including accessibility settings (which are not always available without an opt in, and can be significantly larger than the author might expect otherwise), to help make sure authors write pages that work for all users.

Great feedback, thank you!

In general I hate these <meta> things, but I think for this use case it makes sense, and I agree 100% that letting rem units behave as intended is a better author experience. Some things to think about:

Use compat or fixed and user or adjustable as the keyword values for the <meta>? Since that better reflects that the initial value is fixed at 16px for compat, and the new value is intended to match user adjustments.

Well, the initial value isn't always 16px. On desktop browsers it is 16px × UA-level scale (see table)

Remap the other absolute size keywords appropriately so that they also scale with medium.

Yes! We planned to do this but appear to have omitted it from the explainer by accident.

Consider remapping the other absolute font-size keywords in a way that reflects the OS text scale, which IIRC doesn't always scale linearly with the body text size.

This is an interesting idea. I don't think we'd want to do both this AND progressive, but maybe. Or maybe if we do this, we won't need progressive at all.

Maybe also allow these keywords in calc() etc. so that authors can interpolate those sizes, too?

Recommend to authoring tools that they offer simulation of various size preference including accessibility settings (which are not always available without an opt in, and can be significantly larger than the author might expect otherwise), to help make sure authors write pages that work for all users.

Agree that nudges from author tooling would go a long away toward ensuring these <meta>-enabled pages work well for all users.

In general I hate these <meta> things, but I think for this use case it makes sense, and I agree 100% that letting rem units behave as intended is a better author experience.

Yeah I feel the same way. (I miss the @viewport at-rule.)

Use compat or fixed and user or adjustable as the keyword values for the <meta>? Since that better reflects that the initial value is fixed at 16px for compat, and the new value is intended to match user adjustments.

Well, the initial value isn't always 16px. On desktop browsers it is 16px × UA-level scale (see table)

I'm up for alternative names, though. I proposed legacy for the default value just so it captures the nuanced differences on mobile and desktop (like how on desktop the initial font size is 16px × UA-level scale but on mobile, it is indeed fixed to 16px).

Remap the other absolute size keywords appropriately so that they also scale with medium.

Yes! We planned to do this but appear to have omitted it from the explainer by accident.

I guess I never thought it was worth mentioning, because the other absolute size keywords are sized relative to medium anyway. But I completely agree this is worth calling out!!

Maybe also allow these keywords in calc() etc. so that authors can interpolate those sizes, too?

Ah, do you mean somehow doing something like: calc(font-size-x-large * 2)? I like the idea! I'm wondering, though, if authors would use it. These days, I only ever see things sized with specific <length> values.

The CSS Working Group just discussed [css-env][css-fonts] New `<meta text-scale>` tag to make UA initial font size respond to OS text scale setting, and agreed to the following:

RESOLVED: No longer pursue pem units. Adopt proposed <meta> for opting into adjustable text scale.

The full IRC log of that discussion

<kbabbitt> JoshT: we discussed & resolved to accept a new environment var called preferred-text-scale
<kbabbitt> ... and to add a new CSS unit pem
<kbabbitt> ... so me and davidgrogan and pdr have been working on new explainer
<kbabbitt> ... for new meta tag as well
<JoshT> https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/meta-text-scale.md
<kbabbitt> ... not looking for a resolution on that, just introducing to group
<kbabbitt> ... ^ link to explainer
<kbabbitt> ... in summary, after talking to authors about this, we had some feedback that they don't think pem units would be very useful
<kbabbitt> ... problem we're trying to solve is, when the user sets font scale in OS a11y settings
<kbabbitt> ... that doesn't get reflected on webpages they use
<kbabbitt> ... over 1/3 of users on mobile devices set default font sizes
<kbabbitt> ... feedback we had was , authors just want rem units to work
<kbabbitt> ... they've been told if they use font-relative units everywhere, websites will just have the correct scale
<kbabbitt> ... but that's not happening
<kbabbitt> ... after going through options, we've come back to original idea from 2019
<kbabbitt> ... which is to have a new meta tag
<kbabbitt> ... proposal section in explainer: rather than incorporating into viewport meta tag, this would be a new one
<kbabbitt> ... it's proposed to have 2 options, names to be bikeshedded
<kbabbitt> ... `legacy` which is current behavior for text scaling
<kbabbitt> ... `scale` taking into account OS setting and UA setting for default font size
<kbabbitt> ... explainer has a comparison table
<kbabbitt> ... showing what's affected by these 2 options
<fantasai> -> https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/meta-text-scale.md#comparison-of-legacy-and-scale
<kbabbitt> ... `legacy` has lots of different behaviors depending on mobile or desktop
<kbabbitt> ... `scale` will unify these across mobile & desktop
<emilio> q+
<smfr> q-
<astearns> ack fantasai
<TabAtkins> q+
<kbabbitt> fantasai: we're expecting this to affect initial value of font-size property?
<kbabbitt> ... keywords?
<kbabbitt> ... interpretation of that and rem units
<kbabbitt> ... that put together means that authors could design with idea that initial font-size is user's preferred font size and their page will just work
<kbabbitt> ... leaves us room to contemplate whether we want to adjust the absolute keywords for OS scale
<kbabbitt> ... right now they're fixed multipliers
<kbabbitt> ... we could consider making them adjust based on what font-size actually is
<fantasai> s/font-size/medium font-size/
<kbabbitt> JoshT: we found in our research that, desktop browsers increase default font size, those keywords should also proportionally increase
<astearns> ack emilio
<fantasai> Some OSes don't have a linear scaling of their larger sizes with increases in the base font size
<kbabbitt> emilio: to be clear, 2 big differences
<fantasai> So we could consider making the font-size keywords adjust in the same way
<kbabbitt> ... font-size 16px * preferred scale factor
<fantasai> as the OS, rather than being fixed offsets
<kbabbitt> ... affects media queries and keywords
<fantasai> s/offsets/multipliers/
<kbabbitt> ... feels a bit odd to make the initial value of a property depend on ...
<kbabbitt> ... if you're not changing initial value, just what it computes to, should be fine
<kbabbitt> ... mqs are a big one where ... the one you cannot easily do otherwise, right?
<kbabbitt> ... mqs seems like actual useful thing that this would introduce
<kbabbitt> ... making ems and rems work properly with mqs based on user font scale
<kbabbitt> ... haven't seen keywords used all that much, could get around them if needed
<kbabbitt> ... rem units can be set with font-size
<kbabbitt> JoshT: agree, not aware of authors using keywords much these days
<kbabbitt> ... important to call out medium since that's how UA initial font size is derived
<kbabbitt> ... key feature is that rem units will now work
<kbabbitt> ... in mq scale based on os font size as well
<kbabbitt> emilio: ideally it is much more convenient to be able to do this
<kbabbitt> ... also text-size-adjust would basically be none?
<kbabbitt> ... UAs / authors aren'd expected to do adjustments?
<kbabbitt> JoshT: yes, text size auto is effectively disabled
<kbabbitt> emilio: seems ? to me that it can't be the default behavior
<kbabbitt> ... but a meta tag seems reasonable
<kbabbitt> ... especially since it needs to affect mqs
<astearns> ack TabAtkins
<kbabbitt> TabAtkins: really like this approach, like emilio I wish we could do this by default but compat is out of whack
<kbabbitt> ... meta tag that makes this not overly complicated sounds great
<kbabbitt> s/?/unfortunate/
<romain> +1
<kbabbitt> astearns: JoshT you opened this to introduce, but no objections yet
<kbabbitt> JoshT: 2 resolutions: 1. no longer have pem units
<kbabbitt> ... 2. adopt the proposal in the explainer for meta text-scale
<fantasai> PROPOSED: No longer pursue pem units. Adopt proposed <meta> for text scale.
<fantasai> PROPOSED: No longer pursue pem units. Adopt proposed <meta> for opting into adjustable text scale.
<kbabbitt> astearns: don't want to rush, if anyone would like time to look at the explainer, happy to take this up in another meeting
<kbabbitt> astearns: hearing no requests to go slower, any objections to proposed resolution?
<fantasai> RESOLVED: No longer pursue pem units. Adopt proposed <meta> for opting into adjustable text scale.
<astearns> ack fantasai
<kbabbitt> fantasai: the two open questions are 1. naming; 2. whether we allow font-size keywords relationships to each other to be affected
<kbabbitt> astearns: suggest opening a new issue about keyword thing
<kbabbitt> ... on naming, would prefer having a name in the spec at editor discretion that people can open issues on
<kbabbitt> ... don't open an issue until we have something to disagree about
<kbabbitt> JoshT: one other question, what spec should this live in?
<kbabbitt> fantasai: device adaptation
<kbabbitt> JoshT: is that renamed to CSS viewport
<kbabbitt> fantasai: yes.. fonts level 5 then?
<kbabbitt> ChrisL: sounds reasonable
<kbabbitt> astearns: do we have editors for fonts 5 that are up for this?
<kbabbitt> ChrisL: new blood always welcome
<kbabbitt> astearns: if we add a new editor, would it be JoshT or dgrogan?
<kbabbitt> TabAtkins: this is relatively small, I can do it
<kbabbitt> keithamusz: also happy to pick up the work to relieve TabAtkins
<TabAtkins> That works for me too ^_^

@davidsgrogan

It was a surprise and delight to get a resolution on this today. I'd like to say thank you to @davidsgrogan and @progers for all their help! This is my first time taking a new feature in the CSSWG through to a resolution and it wouldn't have happened without their championing and help.

@fantasai

Regarding this follow up question:

whether we allow font-size keywords relationships to each other to be affected

@fantasai Before I create a new issue, the absolute font size keywords are all already defined in the spec as being relative to medium. Do you think any more spec changes are needed?

@JoshTumath

@JoshTumath That works for now, the open question (probably worth marking in the draft with ISSUE) is whether the UA should relationships to match platform conventions. On at least some platforms, larger-sized text doesn't scale linearly along with the medium text.

@JoshTumath

@JoshTumath That works for now, the open question (probably worth marking in the draft with ISSUE) is whether the UA should relationships to match platform conventions. On at least some platforms, larger-sized text doesn't scale linearly along with the medium text.

Ah, I understand. This is the discussion around smaller scaling factors for larger text. Yeah I'll create an issue for that.

I assume that authors aren't generally intentionally relying on the font-size keywords having a specific fixed relationship with each other (but they might be accidentally doing so, just by virtue of using the keywords and designing around the size that results). But if the size is changing anyway as a result of the meta causing them to take the user text scale into account, that's something they'll need to deal with regardless, so it would probably be safe to adjust the ratios.

My feedback as follows is 100% from the perspective of a user, not a developer, as someone who has used the Web with increased font size settings above the default on desktop browsers for many years. I have attempted to comprehensively address the arguments I found made in favor of the opt in meta tag.

From the explainer:

Browsers can’t simply apply the user’s system-level font scale to all web pages, because – if they did – many existing page layouts would break, causing content to be invisible or to lose interactivity.
Authors would need to test their websites before opting in to see if they need to adapt them to protect from overflowing text or content that is too squashed to be able to read or view easily.

Based on my experience, while some unusable UI does occur rarely, 99% of the time, the breakage caused by having an increased font size is purely cosmetic, things like the body being too wide and causing the page to be horizontally scrollable, text in a button wrapping to the next line, and similar cases in which the UI remains fully functional. That is mainly due to the forgiving nature of HTML/CSS, where the page becomes scrollable and contents overflow their container when the developer didn’t anticipate that scenario. This is in contrast to various native UI frameworks, where increasing system text size preferences above the default often results in unusable UI.

You could make the argument that users on desktop browsers can already change the UA’s initial font size in their browser settings, so there’s already a risk that websites could break. That is true, but the vast majority of users don’t do that (compared to approximately 36% of users on mobile OSs), so authors are much less likely to receive complaints about broken content, and therefore are less likely to be aware of it.

That to me is a good argument against an opt in. This is indeed already a problem for the stated small portion of desktop users. But making an opt in for mobile means that the problem would remain often ignored for desktop users. If instead ~40% of a website’s users experienced the visual glitches caused by increased font sizes, that would provide a much greater impetus for web devs to actually fix the problem instead of ignoring the users affected by it.

Also, desktop browsers tend to have large viewports, so content is unlikely to get squashed. Authors are not used to dealing with scaled up text on small mobile-device-sized viewports.

That makes sense if the amount of content or UI being presented is the same on different screen sizes, which is usually not the case. A laptop webpage has more space available than a phone, but websites usually respond by putting more stuff on the screen.

After gathering feedback from authors, we don’t believe pem units are useful. Authors we spoke to described that they are already ‘doing the right thing’ by using existing font-relative units like rem and em, so they would not like to change their pages to use pem everywhere; they would like to continue to use rem and em and are surprised to learn that browsers do not already use OS-level text scales for the UA’s initial font size.

As this states, the authors who use relative units are already trying to respect the user’s preferences, so browsers should just do it. The authors who don’t are using hardcoded px font sizes, which wouldn't be broken by changes to the default font size, only broken where users set a minimum font size.

So please reconsider requiring an opt in, and just make respecting the OS level text scale the default behavior.

As an aside, personally, I would like respecting the user’s preferences to be the default in most cases, not just this one. There is also a comparison to be made with the meta opt in for dark/light system theme. In that case many webpages don’t include the meta tag, and so tens of millions of users have gone out of their way to install extensions which force websites to respect their preference. I think it's pretty clear that many users prioritize respecting their preferences over the possibility of visual flaws, and I would ask you to consider doing likewise in general.

@DanielHerr

@DanielHerr thanks for your feedback. In my heart, I totally agree with you that it would be better if the behaviour that <meta text-scale> opts into is just the default, but I think there are good reasons why we can't do that. Here are my counter-arguments:

things like the body being too wide and causing the page to be horizontally scrollable

That would arguably actually cause websites to violate WCAG2.2's SC 1.4.10 Revflow - especially on small viewports.

text in a button wrapping to the next line, and similar cases in which the UI remains fully functional. That is mainly due to the forgiving nature of HTML/CSS, where the page becomes scrollable and contents overflow their container when the developer didn’t anticipate that scenario.

Yes I totally agree with this point, as long as the text is still readable. But sometimes it can get ridiculously squashed in a way that makes it very hard to read. For example, on LinkedIn.

And on Disneyland Paris's website, the text overflow in the navigation causes a colour contrast violation.

So we have to be really careful not to make things worse. There will be worse examples out there than what I've found.

We also don't want to risk causing a reputational issue with the text scaling feature. If users find their favourites websites are broken beyond what they're willing to tolerate (which will be different for every person), users might think the text scale feature is broken or unreliable and will stop using it.

If instead ~40% of a website’s users experienced the visual glitches caused by increased font sizes, that would provide a much greater impetus for web devs to actually fix the problem instead of ignoring the users affected by it.

If website authors opt-in with the meta tag and receive complaints, then they will have to take ownership of the problem and have impetus to fix it. If all websites suddenly had their text scale increased at the same time (for users who enable it), those websites are probably going to blame the browser vendors and ask them to revert the change.

That makes sense if the amount of content or UI being presented is the same on different screen sizes, which is usually not the case. A laptop webpage has more space available than a phone, but websites usually respond by putting more stuff on the screen.

Agreed. This is why it's important for authors to use font-relative units in their media queries so that dense multi-column layouts change layout based on the text scale.

As this states, the authors who use relative units are already trying to respect the user’s preferences, so browsers should just do it. The authors who don’t are using hardcoded px font sizes, which wouldn't be broken by changes to the default font size, only broken where users set a minimum font size.

Speaking as an author, when I first proposed this change in #10674, I had exactly the same thought. I thought all websites that were following best practices would be fine. But the thing is: often we've all been testing how a website supports zoom, not text scale. Once we did some simple research and looked at how various popular websites handled larger text scales on smartphone-sized viewports, we saw pretty much all of them have problems. It was the same for us at the BBC, and we test this stuff extensively. Look at what happens to our hamburger menu on the BBC Weather website as it gets covered up by the Weather logo.

things like the body being too wide and causing the page to be horizontally scrollable

That would arguably actually cause websites to violate WCAG2.2's SC 1.4.10 Revflow - especially on small viewports.

The thing is, those websites are already violating that rule on desktop or anywhere browsers have font size settings.

We also don't want to risk causing a reputational issue with the text scaling feature. If users find their favourites websites are broken beyond what they're willing to tolerate (which will be different for every person), users might think the text scale feature is broken or unreliable and will stop using it.

I can't speak for how things are on iOS, but at least on Android, the system text scale feature is already unreliable in native apps. I'd estimate maybe 5% of native apps have issues with at least some part of their UI which necessitates going to settings and setting the font scale back to default to use them. So whatever web browsers decide to do isn't going to fundamentally alter the already existing unreliability of the Android text scaling system. And while I can't say for sure what a normal user would think, I believe it's quite clear that those instances are caused by the poor engineering of the individual app.

If website authors opt-in with the meta tag and receive complaints, then they will have to take ownership of the problem and have impetus to fix it. If all websites suddenly had their text scale increased at the same time (for users who enable it), those websites are probably going to blame the browser vendors and ask them to revert the change.

I'm afraid you are overly optimistic about how much website owners will be concerned about the issue. I expect that most websites just won't bother to include the opt in, the same way that most websites disregard system preference to disable animations. I think it's more likely for websites to just ignore the issue than to complain to browser vendors about it, same as they've always done on desktop. With the opt in there is less pressure to fix the problem because only desktop users are affected.

Navigation Menu

Repository navigation

[css-env][css-fonts-5] New `<meta text-scale>` tag to make UA initial font size respond to OS text scale setting #12380

Background

Proposed resolutions

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-env][css-fonts-5] New <meta text-scale> tag to make UA initial font size respond to OS text scale setting #12380

Description

Background

Proposed resolutions

Activity

JoshTumath commented on Jun 21, 2025

tabatkins commented on Jun 23, 2025

fantasai commented on Jul 1, 2025

davidsgrogan commented on Jul 2, 2025

JoshTumath commented on Jul 2, 2025

css-meeting-bot commented on Jul 9, 2025

JoshTumath commented on Jul 9, 2025

JoshTumath commented on Jul 9, 2025

fantasai commented on Jul 10, 2025

JoshTumath commented on Jul 10, 2025

tabatkins commented on Jul 11, 2025

DanielHerr commented on Jul 14, 2026

JoshTumath commented on Jul 17, 2026

DanielHerr commented on Jul 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

[css-env][css-fonts-5] New `<meta text-scale>` tag to make UA initial font size respond to OS text scale setting #12380