[css-env][css-values] UAs inconsistent in how OS font settings affect the default font-size `medium`

[JoshTumath]

EDIT: Progress update 2025-05-22

CSSWG resolved to adopt:

• an env(preferred-text-scale) variable, which returns a multiplier for the OS or UA text size scaling. e.g. if the user increases the font scale in their OS accessibility settings to 150%, the env() var returns 1.5. Authors can use it as a multiplier in a calc().
• a <length> unit called pem, which returns a length multiplied by the preferred-text-scale. Authors can use it for sizing any content on the page and use it in media queries. The exact definition of pem is still in discussion.

@davidsgrogan, @progers and I have published an Explainer doc for env(preferred-text-scale):
https://github.com/w3c/csswg-drafts/blob/main/css-env-1/explainers/env-preferred-text-scale.md

The draft spec for env(preferred-text-scale) is at:
https://drafts.csswg.org/css-env-1/#text-zoom

env(preferred-text-scale) and pem are working names, for now. They may change. We have asked for async resolution of the preferred-text-scale name to confirm agreement of the environment variable name.

---

Context

Authors typically don't set an explicit absolute font-size on the root (e.g. font-size: 32px). They know that the default font-size is 16 CSS pixels, and so they size fonts relative to that initial font-size. For example, they might set a heading to be font-size: 2rem, expecting a computed value of 32px by default.

They do this because they have been taught it's best practice to use relative lengths rather than absolute lengths for accessibility reasons. They are taught that doing so will respect when the user changes the default font size in their operating system or user agent's settings.

Problem

While medium does always seem to compute to 16px by default, that's not actually explicitly defined in the spec. That seems to be the de facto standard. There is no explicitly defined default font size or explanation into exactly how or whether the user agent should change the default font size based on any accessibility settings.

Here is how different OSs and user agents respond to font size changes in the OS accessibility settings:

On Android devices:

• Chrome: ❌ No change, 🔎 except in WebViews (see comment below)
• Firefox: ✅ Does change initial font size

On iOS devices:

• Safari: ❌ No change

On Windows:
Firefox, Edge and Chrome: 🔎 Zooms in entire content

At the BBC, we discovered this issue when noticing that web pages rendered in a Web View in iOS apps don't scale with the iOS Settings app's text size setting by default. As others have noted in #3708, this issue also affects PWA experiences -- especially scenarios where no browser chrome is visible and also there's no browser UI to change the default font size.

It feels like CSS needs to be more explicit about how the user's font size accessibility settings should be respected. Users and authors may be surprised by how the default font size often isn't affected by the operating system settings.

Workaround on iOS

Apple also provide a set of vendor-prefixed values for the font property to set the font styles (including font-size), based on a feature they've branded 'dynamic type'. This is explained in an article on system fonts on the WebKit blog.

body {
  font: -apple-system-body;
  font-family: initial;
  font-weight: initial;
}

For more info on this practice, see: https://www.tpgi.com/text-resizing-web-pages-ios-using-dynamic-type/

What the spec currently says

The initial value of the font-size property is medium. However, according to the specs, the <absolute-size> values (small, medium, large, etc) are defined by the user agent. The specs do not in any way prescribe what the size should be.

CSS2 defines roughly what it should be:

The following table provides user agent guidelines for the absolute-size mapping to HTML heading and absolute font-sizes. The medium value is the user’s preferred font size and is used as the reference middle value.

CSS Fonts Levels 3 and 4 are very vague:

The following table provides user agent guidelines for the absolute-size scaling factor and their mapping to HTML heading and absolute font-sizes. The ‘medium’ value is used as the reference middle value. The user agent may fine-tune these values for different fonts or different types of display devices.

Proposed solutions

Solution 1: Define medium more explicitly in the spec

The CSS Fonts spec should define that medium is 16px by default, when the user hasn't changed any font settings or zoom levels in the user agent. If the user changes their font settings, the computed value of medium would change accordingly.

Solution 2: Opt-in using a new font-size value such as system

There could be a new font-size value like system, which would be defined as 16px by default but also defined to respect the user agent's font size settings.

Authors would be encouraged to set this new system value on their root element as a new best practice.

I don't know if it would be useful, but there could be multiple system font sizes, like system-body, system-heading, etc.

This solution has the disadvantage that it would not affect media queries that use relative font sizes.

Solution 3: Opt-in using HTML <meta viewport>

See: #3708 (comment)

[myakura]

fyi there's a discussion in the past #3708

[flashymittens]

As a webdev I’d prefer that browsers fixed their problems. Specification punishing those who did the right thing (as solution 2 will do) is not the way.

[JoshTumath]

fyi there's a discussion in the past #3708

Thank you, that's really helpful. I've read through the thread, and I see there was a conclusion to solve the problem with a meta tag, but then the discussion was closed after this comment from @cookiecrook.

Closing the loop on this. Since the discussions last Fall, iOS Safari has shipped a per-site font size setting, so my understanding is that we no longer need an author opt-in.

However, we can't utilise the setting in Web Views. In web pages that will only be used in Web Views inside native apps, there is no way to toggle the page to respecting the iOS-wide 'dynamic type' font setting. I imagine the situation is the same with PWAs.

And what about other platforms? As they evolve, the settings around how the default font size is established may change in the future. I think we need to clearly define how the default font size should be established in the spec. I don't think the issue is resolved in #3708.

This counterargument was also given:

I don’t think that’s a CSS problem. Any browser (including a PWA wrapper web view) can add a font size controller.

I disagree. Let me give the use-case of the BBC News and Sport apps.

Most article and video pages in the apps can be rendered natively, and therefore use the OS font scale setting. However, there are some articles that include content that we can't render in the app, so we embed the web page version inside (but remove the website navigation and footer so that it still looks like a native app page).

On those embedded web pages in a Web View, we're not going to give them a font size controller. Why should they need to do that? They've already expressed their font size preference in the OS settings. Why can't we respect that?

[JoshTumath]

Another point to mention when considering solutions: relative units in media queries are based on the initial value, so relative typography units like rem or em in a media queries will benefit if we are respecting the operating system's font size settings. This is probably authors' expected behaviour.

I'm going to give this an Agenda+ label because #3708 was closed without a CSSWG meeting resolution.

[JoshTumath]

Me and @Samua11y have discovered the way font scaling works in Chrome on Android is different depending on whether you're in the browser or in a Web View in an app (I have not tried PWAs).

This is how the font is scaled on the BBC Sport app in a Web View. Notice how just the text has been scaled up, but not margins, padding or gaps, even though they are sized using rem and em units.

This is how I would expect that page to look simply by scaling the font size. This screenshot was taken on Firefox on desktop after 'text-only zoom' to increase the font size. In this way, the rem and em units are affected by the zoom.

So we can see from this that, in Web Views, Chrome is using a text inflation algorithm that's increasing the font size after the CSS computed values for font-size and relative font units have been determined.

[cookiecrook]

On those embedded web pages in a Web View, we're not going to give them a font size controller. Why should they need to do that? They've already expressed their font size preference in the OS settings. Why can't we respect that?

Apple originally shipped Dynamic Type as a single setting for all apps on the system. Unfortunately, a large percentage of third party apps did not support the extra large accessibility font sizes, so the user's experience was pretty broken. They would constantly have to adjust the system size to its max functional size in one of these broken apps, and then readjust to their larger preferred size in other properly coded apps. To account for this problem, iOS added the ability to set a per-app font size.

Likewise, the Web is full of different sites, some of which support adjustable font sizes well, and some which do not. So Safari, as the browser, added per-site font-size control. My opinion is that any native app operating as a browser (includes a web view that can display an indeterminate web source) should also add the ability for the user to adjust their font size. This includes apps like Twitter(X) and Gmail that include a browser for links from social posts or email.

In contrast to the browser-type usage of web views, any native app that includes a web view displaying known content (e.g. Electron apps like Slack) should be handling their own font size control... For example, Slack for Mac does this with Cmd +/- and/or with a "zoom preference in its app Settings. Some read the system preference and pass the base size through to the web view as a JavaScript or CSS variable. There are a dozen ways for native apps to support a user's preferred font size, and IMO none of them require additional CSS features.

[JoshTumath]

Thanks for the response, @cookiecrook. I've been chatting with some of our accessibility team at the BBC, @Samua11y and Andy Ronksley, and we've thinking about the points that you've made.

I can see from what you're saying how iOS is trying to account for apps and websites that are scaling fonts very inconsistently. Also, I'd just like to make clear that this issue is about finding an interoperable solution that that can work across all user agents, and is not just about Safari on iOS.

My opinion is that any native app operating as a browser (includes a web view that can display an indeterminate web source) should also add the ability for the user to adjust their font size. This includes apps like Twitter(X) and Gmail that include a browser for links from social posts or email.

We disagree with this. A key thing I think I need to explain about the BBC's use case is that our BBC News and BBC Sport apps are architected with a mixture of native and Web View pages. For example, pages with live feeds are shown in a Web View because a UI for them has not been built natively.

In this context, users would not expect a control for them to change the font size of the Web View. They would expect the font size that they set either the OS settings or app settings to be reflected both in the native pages and web-based pages of the app. We've actually had quite a few complaints from our users about how the font size in the web views don't match the pages in the app built with a native UI (we've worked around this for now using font: -apple-system-body).

Apple originally shipped Dynamic Type as a single setting for all apps on the system. Unfortunately, a large percentage of third party apps did not support the extra large accessibility font sizes, so the user's experience was pretty broken. They would constantly have to adjust the system size to its max functional size in one of these broken apps, and then readjust to their larger preferred size in other properly coded apps. To account for this problem, iOS added the ability to set a per-app font size.

It's certainly good that iOS provides these workarounds for its users. Nevertheless, there is still an expectation on native app developers to properly conform to the OS font size setting ('dynamic type'). Likewise, I think we can still expect that of web developers as well and we should be able to allow them to do the right thing in accommodating for the OS or user agent font size settings being changed.

This is good for users because it reduces their cognitive overhead. It is better for users if they can set their preference once and authors and user agents accept that. For example, for users who experience eye strain that gets worse during their session on a device, they may want to keep increasing the font size, and it would be better for them if they only had to do it once.

The onus should be on us as authors and as user agents to make sure websites look correct for users, not the users themselves. I don't want to make them do the hard work of getting the font size right when they've already expressed a preference.

We are concerned that users are less likely to try fixing the font size for them on a per site basis rather than globally.

Some read the system preference and pass the base size through to the web view as a JavaScript or CSS variable. There are a dozen ways for native apps to support a user's preferred font size, and IMO none of them require additional CSS features.

@Samua11y did look into this and found that to do this would require a mapping table to match the dynamic type size in UIContentSizeCategory to the web view font, which was much more complex than if we simply had a way to get the user agent to conform to the OS settings.

Also, changing the font-size at the root not will affect the initial font-size, so relative font units in media queries will not be affected. (There are, of course, workarounds to that, like using container queries, but that's not ideal.)

(I can't find the screenshot that demonstrates the issue well. I'll see if I can find it tomorrow.)