This is useful context, thanks Chris, that helps mitigate my concerns. I didn't realize the perf cost that it entailed either. As long as we capture all of this context in in the ChromeStatus entry for “Anticipated spec changes” so that these considerations/tradeoffs are well captured there, as well, this sounds reasonable to me.
Thanks, Alison On Monday, May 11, 2026 at 4:09:33 PM UTC-7 Chris Harrelson wrote: > Hi Alison, > > On Mon, May 11, 2026 at 3:44 PM 'Alison Maher' via blink-dev < > [email protected]> wrote: > >> 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. >> > > https://www.w3.org/2026/02/19-aria-minutes.html > > Summary points (my emphasis): > * There was no clear consensus that we must adhere strictly to the letter > of WCAG 2; maybe keeping fonts large enough (as Chromium's implementation > already generally does) is good enough. (The CSSWG discussions had a > similar flavor.) > * A mention that WCAG 3 may add nuance allowing compliance without > "hammers" as large as what I proposed in issue 12886. > > Unfortunately, WCAG 3 does not appear to be close to being a standard at > this time. Given that, and lacking clear real-world evidence of problems, I > think we should ship now, monitor for issues, and be responsive to > standards decisions that come in the future. > > >> > 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? >> > > Unfortunately, I think this will take significant time, especially given > the multi-WG complexity. > > We considered shipping with that heuristic, but would rather add it if we > see a11y problems rather than proactively put in place such a non-standard > behavior. (Our current implementation is in alignment with the existing > spec text.) > > >> > 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? >> > > It's definitely doable (which is part of why we're comfortable proposing > shipping), but it comes at a performance cost because it may require double > layouts to determine font size before applying zoom. > > 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 >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/51b4fc90-c7b1-49ea-810d-9a80611f9989n%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/ebbc5d63-9fd2-4807-89d6-d877b70105bbn%40chromium.org.
