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