Re: [csswg-drafts] [css-fonts-5] Should absolute font size keywords scale at different rates depending on user's preferred text scale? (#12475)

The CSS Working Group just discussed ``[css-env][css-values] UAs inconsistent in how OS font settings affect the default font-size `medium` ``, and agreed to the following:

* `RESOLVED: When opting into user-preferred font-sizing, the UA tweaks not only medium, but also the other absolute font-size keywords may be adjusted non-uniformly to match the user's preferred text scale`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> fantasai: where are we at with the &lt;meta> font-size stuff? did we resolve on it?<br>
&lt;TabAtkins> ???: dgrogan at Google has drafted a PR to update the spec with our resolutions, just needs merging<br>
&lt;fantasai> s/???/JoshT/<br>
&lt;TabAtkins> JoshT: i think elika's issue was around non-uniform scaling<br>
&lt;TabAtkins> JoshT: body-size text we want to respect the OS pref, but large text like headings, should that scale at the same rate<br>
&lt;TabAtkins> fantasai: one idea i had is that, right now, the meta tag opts us into changing the computed value of 'medium' to match the OS's paragraph text size<br>
&lt;TabAtkins> fantasai: I think that ends up scaling all the other sizes uniformly<br>
&lt;TabAtkins> fantasai: but we could define that th eother keywords (large, small, x-large, etc) also adopt the OS's preferred scaling factors, even if those aren't uniform with the medium scale factor<br>
&lt;TabAtkins> fantasai: in most cases authors set those sizes explicitly anyway as a multiple of their base size<br>
&lt;TabAtkins> fantasai: but this would make the OS's text scale available to the author to compute against<br>
&lt;TabAtkins> fantasai: so that's my suggestion, 'medium' uses the OS's paragraph size, but allow the other keywords to map to other OS sizes, even if they're not uniform<br>
&lt;Rossen5> q?<br>
&lt;Rossen5> ack fantasai<br>
&lt;TabAtkins> JoshT: there's already anothe rissue for that. i'd support it.<br>
&lt;TabAtkins> JoshT: but i'd highlihgt that authors ar emostly just using rem or px units to size text, so it'll probably be tiny impact<br>
&lt;TabAtkins> fantasai: yeah it wouldn't have much impact on existing pages, which is a good thing. too much breakage when people opt in<br>
&lt;TabAtkins> q+<br>
&lt;TabAtkins> fantasai: but it makes the information available to authors so they *can* use the info and scale accordingly<br>
&lt;TabAtkins> fantasai: without us having to create a whole new system<br>
&lt;fantasai> scribe+<br>
&lt;Rossen5> ack TabAtkins<br>
&lt;fantasai> TabAtkins: When you say authors can respond, how do you see them doing that?<br>
&lt;fantasai> TabAtkins: How would you set a heading to large x 1.2?<br>
&lt;TabAtkins> fantasai: large *is* large x 1.2<br>
&lt;TabAtkins> fantasai: these keywords would compute to... they're not a scale factor<br>
&lt;fantasai> TabAtkins: You said authors could respond to these sizes, you mean they can use it?<br>
&lt;fantasai> TabAtkins: Do you mean they could modify them?<br>
&lt;fantasai> TabAtkins: That would only be possible em on a child<br>
&lt;TabAtkins> fantasai: you should be able to use them in calc() too<br>
&lt;fantasai> fantasai: They compute to length values, should be able to use them in calc()<br>
&lt;TabAtkins> TabAtkins: Oh, that's a new feature<br>
&lt;TabAtkins> TabAtkins: now is any of this relevant to the issue at hand?<br>
&lt;fantasai> fantasai: In calc() or in the interpolation functions<br>
&lt;TabAtkins> fantasai: yeah allowing these in calc() or in interpolate() would solve this<br>
&lt;TabAtkins> JoshT: these are currently absolute font-szie keywords, onlya vailable in font-size property<br>
&lt;TabAtkins> JoshT: woudl this mean they're usable anywhere?<br>
&lt;TabAtkins> fantasai: interesting, i'd say no to begin with. if you need font-based sizing you'll just set font-size, then use ems<br>
&lt;ChrisL> q+ to wonder if there is impact on font-size descriptot<br>
&lt;TabAtkins> JoshT: would it even be possible?<br>
&lt;Rossen5> ack ChrisL<br>
&lt;Zakim> ChrisL, you wanted to wonder if there is impact on font-size descriptot<br>
&lt;dgrogan> q+<br>
&lt;TabAtkins> fantasai: no, would need some new calc-keywords since "medium" can mean other things<br>
&lt;TabAtkins> ChrisL: does this affect font-size descriptor?<br>
&lt;TabAtkins> fantasai: does it even take keywords?<br>
&lt;TabAtkins> fantasai: don't think it does<br>
&lt;ChrisL> https://drafts.csswg.org/css-fonts-5/#font-size-desc<br>
&lt;Rossen5> ack dgrogan<br>
&lt;TabAtkins> dgrogan: point of order - we ahve a separate issue for this topic<br>
&lt;TabAtkins> dgrogan: which of these issues are we discussing?<br>
&lt;JoshT> Ah, I found the issue https://github.com/w3c/csswg-drafts/issues/12475<br>
&lt;Rossen5> ack dbaron<br>
&lt;TabAtkins> dbaron: i'm nervous about compat with some of this... hard to follow what's being proposed tho<br>
&lt;TabAtkins> fantasai: this is only if you opt into the meta tag<br>
&lt;dgrogan> q+<br>
&lt;Rossen5> ack dgrogan<br>
&lt;TabAtkins> dgrogan: so we could do what elika is proposing<br>
&lt;TabAtkins> dgrogan: could also let authors opt into a uniform scale explicitly<br>
&lt;TabAtkins> dgrogan: with the current 'scale' keyword in the meta<br>
&lt;TabAtkins> dgrogan: note that the uniform scale is the only thing authors have requested<br>
&lt;TabAtkins> dgrogan: we could have another keyword for the non-uniform scale, but we haven't seen requests for that yet<br>
&lt;TabAtkins> dgrogan: like "scale non-uniform"<br>
&lt;TabAtkins> fantasai: what benefit would it bring to the authors to have the non-uniform scale? if they want uniform they can just use ems based on the default font size<br>
&lt;JoshT> q+<br>
&lt;Rossen5> ack fantasai<br>
&lt;TabAtkins> s/non-uniform/uniform/<br>
&lt;TabAtkins> dgrogan: i see what you're saying. making it non-uniform would still let you get uniform<br>
&lt;TabAtkins> fantasai: yeah, and they'd get that by default by just using standard existing authoring practices<br>
&lt;TabAtkins> JoshT: I have some thoughts on this but I can avoid solutionizing while we resolve on the keywords<br>
&lt;fantasai> PROPOSED: When opting into user-preferred font-sizing, the UA tweaks not only medium, but also the other absolute font-size keywords may be adjusted non-uniformly to match the user's preferred text scale<br>
&lt;TabAtkins> JoshT: looks good, but q. haven't discussed by how much they'll scale. is that editors discretion or UA?<br>
&lt;TabAtkins> fantasai: the editor will ahve to figure out how to describe it, but UA will have to figure out what info they have available.<br>
&lt;TabAtkins> fantasai: [describes a scenario about how to map OS scales to the UA scale, especially when their might be different scale amounts]<br>
&lt;TabAtkins> fantasai: complicated to map the scales together but i think we can leave that to UA discretion<br>
&lt;TabAtkins> fantasai: with some suggestions on how to do it<br>
&lt;TabAtkins> RESOLVED: When opting into user-preferred font-sizing, the UA tweaks not only medium, but also the other absolute font-size keywords may be adjusted non-uniformly to match the user's preferred text scale<br>
&lt;TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/12475<br>
</details>


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


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

Received on Wednesday, 3 December 2025 17:38:05 UTC