Thanks for the additional details. > I've proposed a solution in issue 12886 (and commented there about it) that I think satisfies all of the font sizing concerns. We discussed that solution at both the CSSWG and ARIA WG.
Are there minutes we can link to for the ARIA WG discussion, or was it more informal? Mainly looking to understand whether there’s broader agreement from that group on a path forward. > The team is comfortable changing the implementation to match that solution or another solution if there is a resolution to adopt it. Do we expect that reaching a resolution here will take significant time? If so, did we consider shipping with the proposed adjustment that we believe meets WCAG requirements, monitor the rollout and utilize results to help inform the long-term resolution in the CSSWG issue instead? > We don't think a potential change will impact many users, and even then, it will just make fonts a bit bigger than before. I noticed the CSSWG minutes from January suggested prototyping the proposal and returning with demos. Have we explored that path and found it to be non-trivial, or did we potentially come to the conclusion that we don't think this will be a concern in practice, and there is a good chance the resolution will end up being "no change" in the end? Thanks, Alison On Saturday, May 9, 2026 at 2:38:44 AM UTC-7 Daniel Bratell wrote: > This seems like a great feature that I expect to get a lot of use. > > That said, I find the accessibility issue a bit counter-intuitive. The > concern is that by increasing the font size too much, there won't be room > to further grow it, and therefore the growth will possibly (depending on > resolution of the issue) be limited by default to 200%? > > If anything I would, from an accessibility view point, be worried about > text automatically shrinking despite user attempts at making it bigger. > > Have I missed something central? > > Either way, I think this can be tuned post-release without harming either > users or adoption or site owners. I am a bit disappointed that WebKit and > Mozilla have not found time to express support, but they have had time to > voice objections so I hope they will come along after this is in Chromium. > > LGTM1 > > /Daniel > On 2026-05-09 00:31, Chris Harrelson wrote: > > (API owners hat off, I helped with this feature a bit.) > > On Fri, May 8, 2026 at 8:18 AM 'Alison Maher' via blink-dev < > [email protected]> wrote: > >> Hi Kent, >> >> This looks like a useful feature with clear developer interest, based on >> [css-fonts-5] >> Feature for making text always fit the width of its parent · Issue #2528 · >> w3c/csswg-drafts <https://github.com/w3c/csswg-drafts/issues/2528>. >> One minor question is whether this issue might fit well under the >> “Initial public proposal” section? >> >> > Regarding accessibility, there is one open issue ( >> https://github.com/w3c/csswg-drafts/issues/12886). While we may slightly >> adjust the behavior once a resolution is reached, the risk of breaking >> existing websites would be very low. Therefore, we believe it is safe to >> ship the feature in its current state. >> >> I’m somewhat cautious about shipping with known accessibility concerns >> under the assumption that it can be adjusted later. Could you provide more >> detail on the potential user impact? It would also be helpful to understand >> what changes this issue might introduce and why they’re expected to be low >> risk for sites adopting the feature, potentially in the “Anticipated spec >> changes” section. >> > > I've proposed a solution in issue 12886 (and commented there about it) > that I think satisfies all of the font sizing concerns. We discussed that > solution at both the CSSWG and ARIA WG. The team is comfortable changing > the implementation to match that solution or another solution if there is a > resolution to adopt it. We don't think a potential change will impact many > users, and even then, it will just make fonts a bit bigger than before. I > don't think there will be a significant web compatibility risk shipping > as-is, and we plan to monitor its use in practice and any user feedback. > > On Wednesday, May 6, 2026 at 10:27:16 PM UTC-7 [email protected] wrote: >> >>> >>> >>> *Contact emails* >>> [email protected], [email protected], [email protected] >>> >>> *Explainer* >>> >>> https://github.com/explainers-by-googlers/css-fit-text/blob/main/README.md >>> >>> *Specification* >>> https://drafts.csswg.org/css-text-4/#text-fit-property >>> >>> *Summary* >>> Scales the font size of text nodes to perfectly fit the width of its >>> containing box. This property allows developers to ensure headlines or >>> dynamic content fill the available horizontal space without manual >>> font-size calculations or complex JavaScript workarounds. It provides a >>> robust, CSS-native solution for responsive typography that maintains visual >>> alignment across different screen sizes and varying text lengths. >>> >>> *Blink component* >>> Blink>Layout>Inline >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELayout%3EInline%22> >>> >>> *Web Feature ID* >>> Missing feature >>> https://github.com/web-platform-dx/web-features/issues/3986 >>> >>> *Motivation* >>> In text layout, web authors want to align the lines with both ends of >>> the container, but web authors want to achieve this by adjusting the font >>> size instead of justification. Without this feature, the only option is to >>> manually adjust the font size through trial and error or using JavaScript. >>> Web authors want to fit the text into a container of a specific size >>> without it overflowing. For example, if the container width is narrow and a >>> long word inevitably overflows the container, web authors want to reduce >>> the font size to make it fit within the container. Web authors want to >>> avoid text overflowing the container due to unexpectedly long words used in >>> text translations or when end-users provide arbitrary text. >>> >>> *Initial public proposal* >>> *No information provided* >>> >>> *Search tags* >>> css <https://chromestatus.com/features#tags:css>, css-text >>> <https://chromestatus.com/features#tags:css-text>, text-fit >>> <https://chromestatus.com/features#tags:text-fit> >>> >>> *TAG review* >>> https://github.com/w3ctag/design-reviews/issues/1208 >>> >>> *TAG review status* >>> Issues open. >>> No feedback for a month. >>> >>> *Goals for experimentation* >>> None >>> >>> *Risks* >>> >>> >>> *Interoperability and Compatibility* >>> >>> There is no compatibility risk because this is a new CSS property that >>> affects nothing by default. >>> >>> Regarding accessibility, there is one open issue ( >>> https://github.com/w3c/csswg-drafts/issues/12886). While we may >>> slightly adjust the behavior once a resolution is reached, the risk of >>> breaking existing websites would be very low. Therefore, we believe it is >>> safe to ship the feature in its current state. >>> >>> *Gecko*: No signal ( >>> https://github.com/mozilla/standards-positions/issues/1377) >>> >>> *WebKit*: No signal ( >>> https://github.com/WebKit/standards-positions/issues/637) >>> >>> *Web developers*: Strongly positive ( >>> https://github.com/w3c/csswg-drafts/issues/2528) The CSSWG issue has >>> 110+ votes. >>> >>> *Other signals*: >>> >>> *WebView application risks* >>> >>> None. >>> >>> >>> *Debuggability* >>> DevTools' existing capability for CSS is enough. >>> >>> *Will this feature be supported on all six Blink platforms (Windows, >>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>> Yes >>> >>> *Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> Yes >>> https://wpt.fyi/results/css/css-text/text-fit >>> >>> *Flag name on about://flags* >>> *No information provided* >>> >>> *Finch feature name* >>> CssTextFit >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> False >>> >>> *Tracking bug* >>> https://issues.chromium.org/issues/417306102 >>> >>> *Estimated milestones* >>> Shipping on desktop 150 >>> Shipping on Android 150 >>> Shipping on WebView 150 >>> >>> *Anticipated spec changes* >>> >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5104141688635392?gate=5187835837284352 >>> >>> *Links to previous Intent discussions* >>> Intent to Prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqFRjktXpATLSqzsEOfm7N-vhCUNh3goRz9_wBAJFinfAA%40mail.gmail.com >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. >>> >>> -- >>> TAMURA Kent >>> Software Engineer, Google >>> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d63e66b5-5bf9-493b-a315-a127d3a79048n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d63e66b5-5bf9-493b-a315-a127d3a79048n%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-qwv5V5WD5Odw3D6J_8aedaRJ86FL9AcN%2BOWcm_eZmRw%40mail.gmail.com > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-qwv5V5WD5Odw3D6J_8aedaRJ86FL9AcN%2BOWcm_eZmRw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/51b4fc90-c7b1-49ea-810d-9a80611f9989n%40chromium.org.
