Intent to Ship: CSS `text-fit` property

[TAMURA, Kent]

Contact emails

tk...@chromium.org, ikilp...@chromium.org, ko...@chromium.org

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

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, css-text, 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?

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.

--

TAMURA Kent
Software Engineer, Google

[Alison Maher]

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.
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.

Thanks,
Alison

[Chris Harrelson]

(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 <blin...@chromium.org> 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.
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.

--
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 blink-dev+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d63e66b5-5bf9-493b-a315-a127d3a79048n%40chromium.org.

[Daniel Bratell]

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

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.

[Alison Maher]

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

[Chris Harrelson]

Hi Alison,

On Mon, May 11, 2026 at 3:44 PM 'Alison Maher' via blink-dev <blin...@chromium.org> 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.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/51b4fc90-c7b1-49ea-810d-9a80611f9989n%40chromium.org.

[Alison Maher]

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

[Mike Taylor]

Thanks Alison for raising the concerns (and Chris for the helpful responses).

LGTM2 % updating the context around a11y discussions in Chromestatus for the history books.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ebbc5d63-9fd2-4807-89d6-d877b70105bbn%40chromium.org.

[TAMURA, Kent]

Thank you for the feedback!  I have updated the "Anticipated spec changes” section.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ebbc5d63-9fd2-4807-89d6-d877b70105bbn%40chromium.org.

[Rick Byers]

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

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGH7WqEdjbs96qaJqOirLfh82t-3ouYzKwfEeL2tNbU9Ywwkvg%40mail.gmail.com.