- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 15 Apr 2026 17:01:36 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts-5] <meta text-scale> limits`. <details><summary>The full IRC log of that discussion</summary> <TabAtkins> JoshT: to summarize, at the f2f there was a resolution so, instead of having the "scale" keyword, you'd instead specify a px value<br> <TabAtkins> JoshT: it would kinda be a forcing function for authors to get them to think about what text scale their website actually supports<br> <TabAtkins> JoshT: there was a concern people might copy-paste the meta without thinking about it, not testing, but actually having scaling issues at large text sizes<br> <TabAtkins> JoshT: at BBC we have some concerns about the resolution. wrote in the comment, will summarize<br> <TabAtkins> JoshT: first, don't like the idea of limiting an a11y setting<br> <TabAtkins> JoshT: if the user wants to increase the text scale beyond an author limit, we believe they should bea ble to do that. better for user to receive a broken site experience with readable text<br> <TabAtkins> JoshT: second, how would this affect desktop? right now, without the meta they can increase the text scale to whatever they want<br> <TabAtkins> JoshT: like ein Firefox I can turn on text-only zoom<br> <TabAtkins> JoshT: so say the author sets the meta to a 32px limit, 200%<br> <TabAtkins> JoshT: right now I can exceed that, but what happens when that's in place? can I no longer zoom that much? seems like a backwards step<br> <TabAtkins> JoshT: so we wonder how much websites will actually break.<br> <emilio> q+<br> <TabAtkins> JoshT: we know that there will be some overflowing on websites right now if they just turn them on<br> <TabAtkins> JoshT: but we wonder how much long-term effect there will be.<br> <TabAtkins> JoshT: as a counterproposal, wondering if we could either revert the resolution, or if it's still useful, perhaps have a warning that the UA shows rather than limiting the text scale. so if the user goes beyond the limit, rather than stopping it, the UA just warns it might be problematic for the page<br> <TabAtkins> fantasai: I think we should keep in mind that, prior to this change, we have two modes.<br> <TabAtkins> fantasai: one is "medium" is more or less a fixed number, maybe in a small range<br> <TabAtkins> fantasai: and the new mode where UA is saying "I can handle literally any font size" and can lay out content correctly<br> <TabAtkins> fantasai: the change to using the px-based limit is once you hit that limit, we no longer increase the medium font size. it's clamped to your value. what this does is make it so that text-scale set to 16 is the current legacy behavior<br> <Rossen> ack fantasai<br> <TabAtkins> fantasai: if you use zoom on current pages, that'll keep working. you just dont' get a larger "medium" font size<br> <TabAtkins> fantasai: that shouldn't create any experience regression<br> <TabAtkins> fantasai: if the author wants to write their pages to scale they can pick a larger font size, but this makes it clear that you're decalring you can support up to this amount<br> <TabAtkins> fantasai: devtools could help with this, giving a slider up to the declared max to make it easier to scale the value manually<br> <TabAtkins> fantasai: or could give a warning if the max is too small<br> <JoshT> q+<br> <TabAtkins> fantasai: but I don't think we should revert, most sites are only designed for a small range. better to lock the text size until the user employs a page zoom isntead<br> <dgrogan> q+<br> <TabAtkins> emilio: I have a similar feeling to elika<br> <TabAtkins> emilio: we can't do this by default precisely because sites can't actually do arbitrary sizes<br> <romain> q+<br> <Rossen> ack emilio<br> <TabAtkins> emilio: if they copy the "scale" keyword, they'll be declaring they can, and that wont' work. that'll be bad for users<br> <TabAtkins> emilio: the logical conclusion of your argument is we should do this anyway and let it break website layouts<br> <PaulG> q+<br> <TabAtkins> emilio: maybe a fair take, but people weren't happy with that<br> <TabAtkins> JoshT: two points. first, clarifying the expectation when user tries to go beyond the limit<br> <TabAtkins> JoshT: are we switching to zooming, or just not allow more increases?<br> <TabAtkins> JoshT: second, my concern about copypaste<br> <TabAtkins> JoshT: if we keep it on a length values, my concern is authors will see a best practice declaring you should support scaling up to 200%, then just copy that as the limit. that's not allowing authors to think if they should support more.<br> <TabAtkins> JoshT: at BBC we do know of places where users want to increase their text scale more<br> <Rossen> ack JoshT<br> <TabAtkins> fantasai: once you hit the limit, the zooming functionality of the browser should be exactly as it is now for pages without the emeta<br> <TabAtkins> fantasai: this just means the "medium" font size is potentially larger. but whatever *else* you browser does with zooming will take effect.<br> <TabAtkins> fantasai: the *only* thing this meta tag does is change the font-size keywords. no other functionality is affected or restricted, you're just likely to start at a better place.<br> <Rossen> sck dgrogan<br> <TabAtkins> dgrogan: wrt this being a regression for users<br> <Rossen> ack dgrogan<br> <TabAtkins> dgrogan: right now in Chrome in the a11y UI, we allow the user to change the default font size, "medium", to a max of 72px, 600%<br> <TabAtkins> dgrogan: I think if we stick with the resolution, if an author specifies "32", that'll be a regression for users. don't see how it's not<br> <TabAtkins> dgrogan: so if someone has been surfing around on Chrome with font set to 400%, a lot of sites are broken, sure, but at least they can read some of it<br> <TabAtkins> dgrogan: then if an author declares they want to limit it to 200%, this user might not be able to use the site at all anymore<br> <TabAtkins> q+<br> <Rossen> ack romain<br> <emilio> I'm not sure I buy that, isn't that the whole point of introducing this opt-in?<br> <TabAtkins> romain: ultimately I think it comes down to whether the author can decide what is best<br> <emilio> q+<br> <TabAtkins> romain: if authors can set the max font size, they'll ultimately have to bring in other stakeholders. designers might declare a 200% even if the layout could take 300%, 400%. Users should be the one deciding if a little layout breakage is okay for them<br> <TabAtkins> romain: also this isn't a setting that can be easily set per page, it's a bit more of a general setting<br> <TabAtkins> romain: so if you ahve a large font size, it's nice that ever page respects it<br> <Rossen> ack PaulG<br> <TabAtkins> PaulG: i have another disability use-case, where a user has font settings high but uses magnification, not page zoom.<br> <TabAtkins> PaulG: they'd like to opt out of the feature entirely, or maybe just on a specific page that's more complex<br> <TabAtkins> PaulG: so for them it makes sense to use their own tooling rather than using os settings<br> <TabAtkins> fantasai: browsers settings override OS settings, if the user sets a text size specifically that'll be used<br> <TabAtkins> PaulG: yeah in my scenario the user has magnification tools, and thus hasn't changed browser settings.<br> <TabAtkins> PaulG: in this scenario, it'll be harder for them to use...<br> <TabAtkins> fantasai: isn't that a concern with the existing text-scale feature?<br> <TabAtkins> PaulG: no, they're not using text scaling at all<br> <TabAtkins> fantasai: your concern is that this would make the brwoser change the font scaling. that woudl be an objection ot the scaling feature at all, not this limit<br> <TabAtkins> PaulG: okay fair<br> <fantasai> scribe+<br> <emilio> q-<br> <Rossen> ack TabAtkins<br> <fantasai> TabAtkins: Given the range of realistic values that we see in practice (e.g. Chrome can only do up to 600%) and those are rare<br> <fantasai> TabAtkins: I don't think we're saving much from authors for doing this.<br> <fantasai> TabAtkins: Opting into infinite scale is not correct<br> <fantasai> TabAtkins: They're opting into 2-300% scale<br> <fantasai> TabAtkins: That's not an enormous range to cover<br> <fantasai> TabAtkins: It's fine for them to choose a broken layout, if it results in text being the size they want<br> <fantasai> TabAtkins: We're overengineering this for no user benefit<br> <miriam> +1<br> <fantasai> TabAtkins: Authors will probably copy-paste a value specified in a tutorial, which will probably be 200% zoom<br> <fantasai> TabAtkins: And that might be inappropriate for people who need the large font sizes and will accept the consequences of it<br> <fantasai> TabAtkins: So I think we should remove the limit and go back to infinite<br> <Rossen> ack fantasai<br> <TabAtkins> fantasai: the reason we brought this up is there are text sizes... the goal is, let's match the text scale on the OS, give pages access to that<br> <TabAtkins> fantasai: there is a smaller range of text size settings in our OS that typical users will use, but there is a switch for a11y settings that will blow it up more.<br> <TabAtkins> fantasai: we're not piping that to web pages now because that *will* break<br> <TabAtkins> fantasai: for users that are willing to accept breakage, then the text scale shouldn't actually limit them<br> <TabAtkins> fantasai: but in terms of copypasting 200%, the author should put in the effort to scale more and say they can declare a larger range of sizes<br> <TabAtkins> fantasai: otherwise we'll have to create an artifical limit for broken webpages, even for pages that can opt into a larger value<br> <vmpstr> q+<br> <TabAtkins> fantasai: if we have the limit, people can *say* they can do more than 300% and we can trust them, versus having to assume nobody can actually exceed 300%<br> <fantasai> s/for broken/to avoid broken/<br> <TabAtkins> vmpstr: is there a middle ground? like volume controls, you can reach a site-specific limit but then can go beyond that with a toggle somewhere<br> <TabAtkins> vmpstr: so website has some control over the expected max but users are allowed to go further<br> <Rossen> ack vmpstr<br> <Rossen> ack dbaron<br> <TabAtkins> dbaron: I've confused mysefl a bit, but I think my inclination is to agree with the argumetns to revert the resolution.<br> <dgrogan> q+<br> <TabAtkins> dbaron: eh, retract, not sure anymore, i'm confused about my argument<br> <TabAtkins> dgrogan: there might be a desktop vs mobile thing that we ahven't really discussed, too<br> <TabAtkins> dgrogan: on mobile the android settings only go up to 2x (not sure about ios)<br> <TabAtkins> dgrogan: that's where pages tend to really break<br> <TabAtkins> dgrogan: that's where we heard from authors that they need access to the text scale, but we couldnt' apply it generally<br> <TabAtkins> dgrogan: i couldn't see on android authors not being able to scale up to the max that users want<br> <TabAtkins> dgrogan: on desktop we allows users to go up to 600%, and of course some things break, but some users need it regardless to use the web at all<br> <TabAtkins> dgrogan: what's the iOS max text scale on iphone?<br> <Rossen> ack dgrogan<br> <TabAtkins> fantasai: trying to find the settings<br> <Rossen> ack fantasai<br> <TabAtkins> fantasai: i think by default we allow up to 200%, but i think we allow larger settings<br> <TabAtkins> fantasai: one diff between deskto pand mobile, on dekstop authors that need larger text might just bump their screen resolution, that has a text-scaling effect<br> <TabAtkins> fantasai: so the interaction with what the author sees is a bit different<br> <TabAtkins> (That sounds like just another route to page zoom, fwiw.)<br> <schenney> Gemini claims 15x, if you believe that.<br> <TabAtkins> fantasai: argh, can't find the advanced setting. i know it just gets really big.<br> <TabAtkins> fantasai: but i don't think we can allow unboudned feeding of an enormous medium font size to a site<br> <TabAtkins> fantasai: the point of this is for the page to say "hey i can handle more than 16px, give them to me".<br> <TabAtkins> fantasai: if we let them declare the size they can support, those that *cna* go bigger can declare they can actually go bigger<br> <TabAtkins> Rossen: can the decalred value be a transition threshold, not a hard cap?<br> <TabAtkins> Rossen: before the limit the os scale takes pref and affects "medium"<br> <TabAtkins> fantasai: that's what i'm saying, once you hit the limit we stop bumping "medium". the rest of the zoom functionalities still work.<br> <TabAtkins> Rossen: and the min floor is 200%<br> <TabAtkins> fantasai: there's no min<br> <TabAtkins> fantasai: it's generally accepted you should definitely be able to handle up to 2x text zoom. but there's no actual limit<br> <TabAtkins> Rossen: okay so we want to keep the scale keyword so authors who can support arbitrary sizes should be able to decalre and use it, but make it optional for conformance?<br> <TabAtkins> Rossen: so the UA *may* warn users when text is beyond the declared value<br> <TabAtkins> Rossen: i'm trying to figure out if there's a middle gorund between keepign the hard limit and dropping the limit<br> <TabAtkins> fantasai: we're not trying to change legacy behavior, this is a new opt-in<br> <TabAtkins> Rossen: i thought we were discussing the "scale" keyword...<br> <TabAtkins> fantasai: yes, that's new<br> <TabAtkins> JoshT: but it is shipped in chrome already<br> <TabAtkins> dgrogan: yeah we're not going to yank that behavior, we're considering it legacy behavior at this point<br> <TabAtkins> fantasai: what we could consider is keepign the scale keyword, but also keep the px limit<br> <TabAtkins> fantasai: and the scale keyword says it's up to a ua-defined limit<br> <TabAtkins> fantasai: might be infinite for chrome, safari might be smaller<br> <TabAtkins> fantasai: if you want higher than the ua limit, you have to say so explicitly what your supported range is<br> <TabAtkins> JoshT: i like a ua-defined limit.<br> <TabAtkins> JoshT: want to make sure we dont' ignore the possibility of a regressiodn on desktop. if they can already do 600%, i don't want authors to be able to turn that off<br> <TabAtkins> fantasai: yeah i could see that if the user has requested to go beyond the limit<br> <TabAtkins> dgrogan: so what would the scale limit actually do?<br> <TabAtkins> fantasai: ther'es two settings the user can give, a preferred font-size but they can live with whatever, the other is a required font size<br> <TabAtkins> fantasai: this feature woudl have no effect on the second case<br> <TabAtkins> fantasai: right now if the page asks what the medium font size is, they get 16px, because that's the legacy. this would opt them into the preferred size as gleaned from the os/browser settings.<br> <TabAtkins> fantasai: up to the specified limit<br> <TabAtkins> fantasai: so if the user-preferred font-size is large, and the page says they can only support up to 20px, the UA wouldn't map "medium" to 72px, it would map to 20px. if there are additional settings like page zoom, those would continue to work.<br> <TabAtkins> JoshT: so the limit would apply to the os-defined text-scale limit, but not a ua-defined text scale setting?<br> <TabAtkins> fantasai: depend son what the UA wants to expose as settings<br> <JoshT> s/text-scale limit/text-scale setting/<br> <TabAtkins> fantasai: browser might offer differetn controls for application text scale and web text scale<br> <TabAtkins> fantasai: user might boost text differently for UI vs books/web<br> <PaulG> If authors need access to this info, why not introduce a system var?<br> <fantasai> TabAtkins: The one feature we have on desktop is default font size, which we can set up to 72px<br> <fantasai> TabAtkins: If we set 'scale' we'll continue to respect it, just 'medium' will also report that size<br> <fantasai> TabAtkins: But with this limit in place, we would restrict you to what the page-set limit was.<br> <fantasai> dgrogan: Today, when user sets their preferred font size, we do change 'medium' on Desktop<br> <PaulG> q+<br> <fantasai> dgrogan: Android is different<br> <fantasai> JoshT: Part of the goal is to unify this system, so both can respect the user preferences<br> <TabAtkins> JoshT: part of the point of the meta tag was to unify the desktop/mobile features so they both respect and respond to the user text scale<br> <PaulG> q-<br> <TabAtkins> PaulG: I think, noticing the problems being raised, but knowing that in safari there's a prefixed variable we can use to honor user settings. if we introduce a system-levle variable, it doens't make the author's job easier but it does make it possible<br> <JoshT> q+<br> <TabAtkins> (note that this was already part of the earlier discussion on this feature)<br> <TabAtkins> PaulG: I think this exposes the values to satisfy those goals, without trampling on user preferences<br> <JoshT> q-<br> <TabAtkins> JoshT: yeah what TAb said, we discussed that but I'll direct you to the explainer<br> <TabAtkins> Rossen: so what can we do here?<br> <TabAtkins> fantasai: i'd like to understand what chrome's text size setting si actually doing?<br> <TabAtkins> fantasai: if you set the font size to 10px, what does that do?<br> <TabAtkins> dgrogan: the desktop text size setting just changes the keyword sizes<br> <TabAtkins> fantasai: so the text scale feature doesn't have an effect currently on desktop?<br> <TabAtkins> dgrogan: a small effect, if the page has the meta it affects the env()<br> <TabAtkins> dgrogan: it receives the product of the OS and browser font scaling<br> <TabAtkins> dgrogan: but that's it, on desktop<br> <TabAtkins> fantasai: i think we need to take it back to the issue, i'd like to chat more with josh<br> <TabAtkins> fantasai: i think it's reasonable to have the scale keyword as well as the specified limit, but i think it is still useful for authors to specify what they can handle<br> <TabAtkins> Rossen: okay, we can take this back to the issue<br> <TabAtkins> Rossen: Hopefully we can drive this to a conclusion in the issue for a quicker resolution next call<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13557#issuecomment-4253949924 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 April 2026 17:01:37 UTC