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.
