LGTM3. I agree we will be able to make breaking changes here as needed to adapt to whatever consensus is reached on the accessibility concern. Everything else looks good.
Rick On Tue, May 12, 2026 at 1:12 AM TAMURA, Kent <[email protected]> wrote: > Thank you for the feedback! I have updated the "Anticipated spec changes” > section. > > On Tue, May 12, 2026 at 8:26 AM 'Alison Maher' via blink-dev < > [email protected]> wrote: > >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ebbc5d63-9fd2-4807-89d6-d877b70105bbn%40chromium.org?utm_medium=email&utm_source=footer> >> . >> > > > -- > 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/CAGH7WqEdjbs96qaJqOirLfh82t-3ouYzKwfEeL2tNbU9Ywwkvg%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqEdjbs96qaJqOirLfh82t-3ouYzKwfEeL2tNbU9Ywwkvg%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/CAFUtAY-%3DL9xAsj7e-xYTRGkyzKWssD_TD%2BnkijNA8zmvtVgigw%40mail.gmail.com.
