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/CAOMQ%2Bw9_9zapvE%2BUsiGpQ4zknsJoi4BjyibCo%2BLhNBkR_Nm6mw%40mail.gmail.com.
