- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 28 Jan 2026 23:31:53 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-fonts-5] Text Fitting: Default scaling limit`. <details><summary>The full IRC log of that discussion</summary> <bramus> tkent: the problem here is that when the user zooms in the page they expects that the text size in ??? and that the content size is viewport oblivious<br> <bramus> … not changed by operation, so text-size is not changed<br> <astearns> s/in ???/will increase/<br> <bramus> … so when the user ??? they need to avoid changing the text size<br> <bramus> … in the issue kizu proposed to add a scaling limit of 1500%<br> <kizu> q+<br> <astearns> s/1500/200/<br> <TabAtkins> q+<br> <bramus> … and people including me proposed to start layout a a point of which physical size is ??? in 100% zoom level<br> <bramus> … so that is we think our way to resolve the issue<br> <bramus> astearns: the summary is int he last comment as well<br> <astearns> ack kizu<br> <bramus> kizu: would be nice if that method worked.<br> <bramus> … I have 3 points<br> <bramus> … 1. is not implemented in the prototype, has updated text-fit but doe snot yet have this implemented<br> <bramus> … would be nice to ahve a prototype to test this<br> <bramus> … will try to prepare a page for the ???limit<br> <bramus> … would be nice if chrome could provide an alternative to look at both cases together and decided<br> <bramus> … then 2 questions about the method<br> <bramus> … 1. the proposed formula for the google method mentions 100% of zoom, so q is when is this calculated? page load or not?<br> <bramus> … once you load a page, then you zoom in and refresh ; will the font size change<br> <bramus> … or once you zoom in, the page has to layout twice to get the 100% zoom value for the font-size<br> <bramus> … 2. related to the proposal about the post-??? font-size<br> <bramus> … see problem: the way text fitting works we first find the breaks with orig font size, then do the text fit and fit all the lines<br> <bramus> … if we takes this value and multiply by zoom factor of the page, the text could overflow<br> <bramus> … will this mean we have an extr aline breaking happening if it doesnt fit, or will it overflow the container and potentially create overflow?<br> <bramus> … if it creates overflow, it is problematic, which goes against SC 1.4.4<br> <bramus> … zooming shouldnot create unnecessary overflow<br> <bramus> … contention between repsonsive typography but you dont want it to overflow<br> <bramus> tkent: for q1<br> <bramus> … intention is to do layout twice<br> <bramus> … one at 100% of zoom<br> <bramus> … for q2, we directly apply the updated font-size before line breaking so it could change line breaking<br> <bramus> astearns: so you could get overflow in that 2nd lahyout depending on the container<br> <bramus> TabAtkins: not inline overflow, would break to a new line<br> <bramus> kizu: if there is 1 word with no breaking oppportunities, then it could<br> <bramus> astearns: which is also the case for the 100% layout as well<br> <astearns> ack TabAtkins<br> <bramus> TabAtkins: dont have strong opinions. I like kent’s proposal to use the larger of the two. seems to satisfy the a11y guidelines while still letting text fitting do its thing<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask about font size limits and nowrap<br> <bramus> … so sgtm<br> <bramus> fantasai: Where is the proposal?<br> <bramus> astearns: last comment<br> <bramus> fantasai: but the feature in general? which spec?<br> <bramus> TabAtkins: in PR<br> <bramus> fantasai: not huge fan of writing a spec and then <missed><br> <kizu> q+<br> <fantasai> s/<missed>/iterating over them over months in the form of a PR/<br> <astearns> ack kizu<br> <bramus> kizu: this could work from what I understand first if th euser is zoomed we do layout twice and then do an extra pass to first break lines, break again if overflow and then replay text fitting<br> <bramus> … only concern how performant this is because the potential problem I see is that if we dont do all that work at 100% zoom, users who use different zoom have perf impact on the page in general<br> <bramus> … if it is ??? I think this is good, but would b enice to look at a prototype and play with it<br> <bramus> … and to see it in action<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask about font size limits and nowrap<br> <bramus> astearns: agree that having a demo of all solutions to this problem is going to be key here, bc there are people with a11y expertise that might want to evaluate<br> <bramus> fantasai: we talked a lot about re=-breaking the line and that makes sense for a good chunk of problems<br> <bramus> … but what is the text is nowrap? does it shrin kdown and fit 1 single line?<br> <bramus> … what if its too small … what do we do in that case?<br> <bramus> iank_: the WCAG reqs are written in such a way that clipping of content doesnt exist.<br> <bramus> … so basically its a rock and hard place situation, WCAG say you must grow always but if you do that you might clip<br> <bramus> astearns: im hearing people express the opinion tha tthis seems promising but that we would like to see it in action<br> <bramus> … so kent, would you be able to prototype this resizign behavior on zoom?<br> <bramus> tkent: yes<br> <TabAtkins> here we go, the feature is currently living in an explainer https://github.com/explainers-by-googlers/css-fit-text/blob/main/README.md<br> <bramus> astearns: that would be the next step<br> <bramus> … and roman to prototype – though at some point it might get implemnted with the hacks<br> <bramus> kizu: I can do it in chrome canary as it has suppport for max values<br> <bramus> … and shows all those situations<br> <bramus> … should be simple enough<br> <bramus> astearns: so lets get that done, and then evaluate (and perhaps iterate), and then show a11y folks<br> <bramus> … does that sound like enough for today, kent?<br> <bramus> tkent: that’s nice, thank you<br> <astearns> ack fantasai<br> <bramus> fantasai: in terms of making this easier to review, looks like these are all against css-text-5 … can we try and be consistent?<br> <bramus> … there is no way to figure out what we are talking about when landing on an issue … can we link all from the top of the spec, of start an ED?<br> <bramus> astearns: do we have a resolution to add this to a draft? dont remember …<br> <bramus> kizu: i think it was done at TPAC<br> <bramus> … we changed it<br> <bramus> astearns: and I made you editor IIRC<br> <bramus> kizu: not sure if I will able to describe this well. Kent and Tab suggested they could do it<br> <bramus> … happy to review the text<br> <bramus> TabAtkins: sure<br> <bramus> astearns: so lets try to get this landed and demos together and see where we go from there<br> <bramus> … thanks kent for joining<br> <fantasai> s/against css-text-5/against css-text-5/tagged against css-fonts-5 but spec is resolved to be in css-text-5/<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12886#issuecomment-3814480919 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 January 2026 23:31:54 UTC