16:07:59 <RRSAgent> RRSAgent has joined #css
16:08:03 <RRSAgent> logging to https://www.w3.org/2026/04/15-css-irc
16:08:03 <Zakim> RRSAgent, make logs Public
16:08:04 <Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference
16:08:24 <emilio> ack fantasai
16:08:34 <Kurt> Kurt has joined #css
16:08:35 <jfkthame> present+
16:08:40 <Rossen> ack emilio
16:08:41 <TabAtkins> fantasai: I think the layout beahvior of resolving auto to zero for sticky insets makes sense, it's probably what you want. no opinion on roundtripping
16:08:41 <Kurt> present+
16:09:05 <TabAtkins> emilio: roundtripping is just not resolving the margin, right? that seems doable. we can try it.
16:09:16 <TabAtkins> fantasai: you'd have to serialize it as "auto" to make the roundtrip
16:09:28 <flackr> q+
16:09:29 <TabAtkins> oriol: yeah layout could have auto become a non-zero margin, then inset treats as zero
16:09:38 <TabAtkins> emilio: all right, seems doable. worth a try at least
16:09:54 <Rossen> ack flackr
16:09:54 <TabAtkins> emilio: I would imagine auto+sticky and messing with computed styles is something we might be able to get away with. we can try.
16:10:16 <TabAtkins> flackr: we're jumping to the conclusion of trying to specify what browsers do, but why is auto treated as zero for sticky? what would it mean if we tried to make auto meaningful for sticky?
16:10:43 <sbender> sbender has joined #css
16:10:48 <sbender> sbender has left #css
16:11:03 <TabAtkins> flackr: also, this roundtripping issue, presumably even aside from sticky if you have "auto" and then check gCS() you get a static value, it's not adaptive. not strictly a roundtrip then
16:11:09 <Rossen> ack dbaron
16:11:23 <TabAtkins> dbaron: might be misremembering, but I think there are many other cases for margins that doesn't roundtrip
16:11:30 <TabAtkins> dbaron: like % margins resolve to px
16:11:35 <TabAtkins> dbaron: that also doesn't really roundtrip.
16:11:53 <TabAtkins> dbaron: at least, that can cause different intrinsic sizing results
16:11:57 <TabAtkins> emilio: and float layout
16:12:32 <TabAtkins> dbaron: in general, you can't really roundtrip from gCS() for some of these properties that do a lot of resolution, even if it "does the same thing" in (most) contexts
16:12:51 <TabAtkins> oriol: it's true that using %s can affect intrinsic contribution, but the element itself kinda stays the same
16:13:59 <emilio> I still think the less gCS magic we have the better, but also can live with either I guess
16:14:01 <TabAtkins> oriol: so I suppose if all browsers are okay with keeping the special auto behavior, we can spec that. for roundtripping I don't have a strong opinion
16:15:07 <TabAtkins> proposed: auto margins are treated as zero for the purpose of calculating stickypos insets
16:15:23 <TabAtkins> proposed: no change to gCS() margin behavior (it still becomes a static length, as usual)
16:15:36 <TabAtkins> RESOLVED: auto margins are treated as zero for the purpose of calculating stickypos insets
16:15:45 <TabAtkins> RESOLVED: no change to gCS() margin behavior (it still becomes a static length, as usual)
16:16:00 <TabAtkins> github-bot: take up https://github.com/w3c/csswg-drafts/issues/13557#issuecomment-4214540289
16:16:01 <github-bot> Topic: [css-fonts-5] <meta text-scale> limits
16:16:01 <github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/13557
16:16:49 <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
16:17:06 <TabAtkins> JoshT: it would kinda be a forcing function for authors to get them to think about what text scale their website actually supports
16:17:33 <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
16:17:45 <TabAtkins> JoshT: at BBC we have some concerns about the resolution. wrote in the comment, will summarize
16:17:51 <TabAtkins> JoshT: first, don't like the idea of limiting an a11y setting
16:18:20 <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
16:18:38 <TabAtkins> JoshT: second, how would this affect desktop? right now, without the meta they can increase the text scale to whatever they want
16:18:45 <TabAtkins> JoshT: like ein Firefox I can turn on text-only zoom
16:18:56 <TabAtkins> JoshT: so say the author sets the meta to a 32px limit, 200%
16:19:15 <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
16:19:24 <TabAtkins> JoshT: so we wonder how much websites will actually break.
16:19:28 <emilio> q+
16:19:39 <TabAtkins> JoshT: we know that there will be some overflowing on websites right now if they just turn them on
16:19:50 <TabAtkins> JoshT: but we wonder how much long-term effect there will be.
16:20:06 <PaulG> present+
16:20:30 <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
16:20:40 <TabAtkins> fantasai: I think we should keep in mind that, prior to this change, we have two modes.
16:20:54 <TabAtkins> fantasai: one is "medium" is more or less a fixed number, maybe in a small range
16:21:09 <TabAtkins> fantasai: and the new mode where UA is saying "I can handle literally any font size" and can lay out content correctly
16:21:42 <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
16:21:55 <Rossen> ack fantasai
16:21:57 <TabAtkins> fantasai: if you use zoom on current pages, that'll keep working. you just dont' get a larger "medium" font size
16:22:04 <TabAtkins> fantasai: that shouldn't create any experience regression
16:22:26 <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
16:22:42 <TabAtkins> fantasai: devtools could help with this, giving a slider up to the declared max to make it easier to scale the value manually
16:23:03 <TabAtkins> fantasai: or could give a warning if the max is too small
16:23:29 <JoshT> q+
16:23:30 <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
16:23:39 <dgrogan> q+
16:23:43 <TabAtkins> emilio: I have a similar feeling to elika
16:23:54 <TabAtkins> emilio: we can't do this by default precisely because sites can't actually do arbitrary sizes
16:24:04 <romain> q+
16:24:07 <Rossen> ack emilio
16:24:12 <TabAtkins> emilio: if they copy the "scale" keyword, they'll be declaring they can, and that wont' work. that'll be bad for users
16:24:26 <TabAtkins> emilio: the logical conclusion of your argument is we should do this anyway and let it break website layouts
16:24:32 <PaulG> q+
16:24:32 <TabAtkins> emilio: maybe a fair take, but people weren't happy with that
16:24:49 <TabAtkins> JoshT: two points. first, clarifying the expectation when user tries to go beyond the limit
16:25:01 <TabAtkins> JoshT: are we switching to zooming, or just not allow more increases?
16:25:07 <TabAtkins> JoshT: second, my concern about copypaste
16:25:48 <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.
16:26:00 <TabAtkins> JoshT: at BBC we do know of places where users want to increase their text scale more
16:26:20 <Rossen> ack JoshT
16:26:23 <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
16:26:48 <TabAtkins> fantasai: this just means the "medium" font size is potentially larger. but whatever *else* you browser does with zooming will take effect.
16:27:16 <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.
16:27:22 <Rossen> sck dgrogan
16:27:27 <TabAtkins> dgrogan: wrt this being a regression for users
16:27:32 <Rossen> ack dgrogan
16:27:47 <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%
16:28:07 <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
16:28:30 <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
16:28:51 <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
16:29:02 <TabAtkins> q+
16:29:02 <Rossen> ack romain
16:29:06 <emilio> I'm not sure I buy that, isn't that the whole point of introducing this opt-in?
16:29:15 <TabAtkins> romain: ultimately I think it comes down to whether the author can decide what is best
16:29:27 <emilio> q+
16:29:57 <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
16:30:10 <TabAtkins> romain: also this isn't a setting that can be easily set per page, it's a bit more of a general setting
16:30:24 <TabAtkins> romain: so if you ahve a large font size, it's nice that ever page respects it
16:30:35 <Rossen> ack PaulG
16:30:44 <TabAtkins> PaulG: i have another disability use-case, where a user has font settings high but uses magnification, not page zoom.
16:31:00 <TabAtkins> PaulG: they'd like to opt out of the feature entirely, or maybe just on a specific page that's more complex
16:31:17 <TabAtkins> PaulG: so for them it makes sense to use their own tooling rather than using os settings
16:31:32 <TabAtkins> fantasai: browsers settings override OS settings, if the user sets a text size specifically that'll be used
16:31:50 <TabAtkins> PaulG: yeah in my scenario the user has magnification tools, and thus hasn't changed browser settings.
16:32:12 <TabAtkins> PaulG: in this scenario, it'll be harder for them to use...
16:32:21 <TabAtkins> fantasai: isn't that a concern with the existing text-scale feature?
16:32:36 <TabAtkins> PaulG: no, they're not using text scaling at all
16:33:02 <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
16:33:04 <TabAtkins> PaulG: okay fair
16:33:08 <fantasai> scribe+
16:33:12 <emilio> q-
16:33:20 <Rossen> ack TabAtkins
16:33:42 <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
16:33:50 <fantasai> TabAtkins: I don't think we're saving much from authors for doing this.
16:33:57 <fantasai> TabAtkins: Opting into infinite scale is not correct
16:34:06 <fantasai> TabAtkins: They're opting into 2-300% scale
16:34:13 <fantasai> TabAtkins: That's not an enormous range to cover
16:34:26 <fantasai> TabAtkins: It's fine for them to choose a broken layout, if it results in text being the size they want
16:34:33 <fantasai> TabAtkins: We're overengineering this for no user benefit
16:34:39 <miriam> +1
16:34:52 <fantasai> TabAtkins: Authors will probably copy-paste a value specified in a tutorial, which will probably be 200% zoom
16:35:08 <fantasai> TabAtkins: And that might be inappropriate for people who need the large font sizes and will accept the consequences of it
16:35:19 <fantasai> TabAtkins: So I think we should remove the limit and go back to infinite
16:35:25 <Rossen> ack fantasai
16:35:48 <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
16:36:10 <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.
16:36:17 <TabAtkins> fantasai: we're not piping that to web pages now because that *will* break
16:36:32 <TabAtkins> fantasai: for users that are willing to accept breakage, then the text scale shouldn't actually limit them
16:37:08 <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
16:37:36 <TabAtkins> fantasai: otherwise we'll have to create an artifical limit for broken webpages, even for pages that can opt into a larger value
16:37:50 <vmpstr> q+
16:38:00 <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%
16:38:01 <fantasai> s/for broken/to avoid broken/
16:38:27 <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
16:38:40 <TabAtkins> vmpstr: so website has some control over the expected max but users are allowed to go further
16:38:45 <Rossen> ack vmpstr
16:38:51 <Rossen> ack dbaron
16:39:21 <TabAtkins> dbaron: I've confused mysefl a bit, but I think my inclination is to agree with the argumetns to revert the resolution.
16:39:27 <dgrogan> q+
16:39:37 <TabAtkins> dbaron: eh, retract, not sure anymore, i'm confused about my argument
16:39:46 <TabAtkins> dgrogan: there might be a desktop vs mobile thing that we ahven't really discussed, too
16:39:57 <TabAtkins> dgrogan: on mobile the android settings only go up to 2x (not sure about ios)
16:40:06 <TabAtkins> dgrogan: that's where pages tend to really break
16:40:08 <JoshT> JoshT has joined #css
16:40:29 <TabAtkins> dgrogan: that's where we heard from authors that they need access to the text scale, but we couldnt' apply it generally
16:40:42 <TabAtkins> dgrogan: i couldn't see on android authors not being able to scale up to the max that users want
16:41:01 <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
16:41:12 <TabAtkins> dgrogan: what's the iOS max text scale on iphone?
16:41:14 <Rossen> ack dgrogan
16:41:17 <TabAtkins> fantasai: trying to find the settings
16:41:26 <Rossen> ack fantasai
16:41:29 <TabAtkins> fantasai: i think by default we allow up to 200%, but i think we allow larger settings
16:41:51 <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
16:42:00 <TabAtkins> fantasai: so the interaction with what the author sees is a bit different
16:42:20 <TabAtkins> (That sounds like just another route to page zoom, fwiw.)
16:42:25 <schenney> Gemini claims 15x, if you believe that.
16:43:08 <TabAtkins> fantasai: argh, can't find the advanced setting. i know it just gets really big.
16:43:08 <TabAtkins> fantasai: but i don't think we can allow unboudned feeding of an enormous medium font size to a site
16:43:18 <TabAtkins> fantasai: the point of this is for the page to say "hey i can handle more than 16px, give them to me".
16:43:54 <TabAtkins> fantasai: if we let them declare the size they can support, those that *cna* go bigger can declare they can actually go bigger
16:43:58 <TabAtkins> Rossen: can the decalred value be a transition threshold, not a hard cap?
16:44:19 <TabAtkins> Rossen: before the limit the os scale takes pref and affects "medium"
16:44:45 <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.
16:44:54 <TabAtkins> Rossen: and the min floor is 200%
16:44:56 <TabAtkins> fantasai: there's no min
16:45:16 <TabAtkins> fantasai: it's generally accepted you should definitely be able to handle up to 2x text zoom. but there's no actual limit
16:46:12 <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?
16:46:31 <TabAtkins> Rossen: so the UA *may* warn users when text is beyond the declared value
16:47:06 <TabAtkins> Rossen: i'm trying to figure out if there's a middle gorund between keepign the hard limit and dropping the limit
16:47:24 <TabAtkins> fantasai: we're not trying to change legacy behavior, this is a new opt-in
16:47:43 <TabAtkins> Rossen: i thought we were discussing the "scale" keyword...
16:47:45 <TabAtkins> fantasai: yes, that's new
16:47:51 <TabAtkins> JoshT: but it is shipped in chrome already
16:48:06 <TabAtkins> dgrogan: yeah we're not going to yank that behavior, we're considering it legacy behavior at this point
16:48:37 <TabAtkins> fantasai: what we could consider is keepign the scale keyword, but also keep the px limit
16:48:51 <TabAtkins> fantasai: and the scale keyword says it's up to a ua-defined limit
16:49:03 <TabAtkins> fantasai: might be infinite for chrome, safari might be smaller
16:49:16 <TabAtkins> fantasai: if you want higher than the ua limit, you have to say so explicitly what your supported range is
16:49:24 <TabAtkins> JoshT: i like a ua-defined limit.
16:49:52 <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
16:50:14 <TabAtkins> fantasai: yeah i could see that if the user has requested to go beyond the limit
16:50:21 <TabAtkins> dgrogan: so what would the scale limit actually do?
16:50:40 <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
16:50:48 <TabAtkins> fantasai: this feature woudl have no effect on the second case
16:51:25 <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.
16:51:37 <TabAtkins> fantasai: up to the specified limit
16:52:18 <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.
16:52:37 <TabAtkins> JoshT: so the limit would apply to the os-defined text-scale limit, but not a ua-defined text scale setting?
16:52:49 <TabAtkins> fantasai: depend son what the UA wants to expose as settings
16:52:55 <JoshT> s/text-scale limit/text-scale setting/
16:53:04 <TabAtkins> fantasai: browser might offer differetn controls for application text scale and web text scale
16:53:16 <TabAtkins> fantasai: user might boost text differently for UI vs books/web
16:53:49 <PaulG> If authors need access to this info, why not introduce a system var?
16:54:52 <fantasai> TabAtkins: The one feature we have on desktop is default font size, which we can set up to 72px
16:55:05 <fantasai> TabAtkins: If we set 'scale' we'll continue to respect it, just 'medium' will also report that size
16:55:18 <fantasai> TabAtkins: But with this limit in place, we would restrict you to what the page-set limit was.
16:55:43 <fantasai> dgrogan: Today, when user sets their preferred font size, we do change 'medium' on Desktop
16:55:47 <PaulG> q+
16:55:50 <fantasai> dgrogan: Android is different
16:56:06 <fantasai> JoshT: Part of the goal is to unify this system, so both can respect the user preferences
16:56:11 <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
16:56:20 <PaulG> q-
16:57:08 <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
16:57:21 <JoshT> q+
16:57:23 <TabAtkins> (note that this was already part of the earlier discussion on this feature)
16:57:41 <TabAtkins> PaulG: I think this exposes the values to satisfy those goals, without trampling on user preferences
16:57:48 <JoshT> q-
16:57:58 <TabAtkins> JoshT: yeah what TAb said, we discussed that but I'll direct you to the explainer
16:58:03 <TabAtkins> Rossen: so what can we do here?
16:58:13 <TabAtkins> fantasai: i'd like to understand what chrome's text size setting si actually doing?
16:58:23 <TabAtkins> fantasai: if you set the font size to 10px, what does that do?
16:58:36 <TabAtkins> dgrogan: the desktop text size setting just changes the keyword sizes
16:58:48 <TabAtkins> fantasai: so the text scale feature doesn't have an effect currently on desktop?
16:59:00 <TabAtkins> dgrogan: a small effect, if the page has the meta it affects the env()
16:59:18 <TabAtkins> dgrogan: it receives the product of the OS and browser font scaling
16:59:23 <TabAtkins> dgrogan: but that's it, on desktop
16:59:41 <TabAtkins> fantasai: i think we need to take it back to the issue, i'd like to chat more with josh
17:00:07 <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
17:00:41 <TabAtkins> Rossen: okay, we can take this back to the issue
17:00:50 <TabAtkins> Rossen: Hopefully we can drive this to a conclusion in the issue for a quicker resolution next call
17:01:33 <TabAtkins> github-bot, end topic
17:01:51 <Rossen> Zakim, end meeting
17:01:51 <Zakim> As of this point the attendees have been jfkthame, Kurt, PaulG
17:01:52 <Zakim> RRSAgent, please draft minutes v2
17:01:53 <RRSAgent> I have made the request to generate https://www.w3.org/2026/04/15-css-minutes.html Zakim
17:02:01 <Zakim> I am happy to have been of service, Rossen; please remember to excuse RRSAgent.  Goodbye
17:02:01 <Zakim> Zakim has left #css