Re: [csswg-drafts] [css-env][css-fonts] New `<meta text-scale>` tag to make UA initial font size respond to OS text scale setting (#12380)

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

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


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12380#issuecomment-3053293717 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 9 July 2025 16:30:42 UTC