#1208: Other Spec Review: [css-text] `text-fit` property

Visit on Github

Opened Mar 23, 2026

Specification

https://github.com/w3c/csswg-drafts/pull/13616

Explainer

https://github.com/explainers-by-googlers/css-fit-text/blob/main/README.md

Links

  • Previous early design review, if any: None
  • An introduction to the feature, aimed at unfamiliar audiences: See the explainer <!-- Can be the specification's or explainer's introduction, or another section. -->
  • A description of the problems that end-users were facing before this proposal: See the explainer <!-- See https://w3ctag.github.io/explainer-explainer/#end-user-need -->
  • Alternatives considered: See the explainer <!-- See https://w3ctag.github.io/explainer-explainer/#alternatives -->
  • Examples of how to use the proposal to solve the end-users' problems: See the explainer <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
  • What do the end-users experience with this proposal: https:// <!-- See https://w3ctag.github.io/explainer-explainer/#describe-proposal -->
  • User research you did to validate the problem and/or design, if any: No public one.
  • Web Platform Tests: Not merged yet. Tests in Chromium repo <!-- Or other tests if this is not a web platform feature. -->

The specification

Where and by whom is the work is being done?

  • GitHub repo: https://github.com/w3c/csswg-drafts
  • Primary contacts:
    • @tkent-google, Google, Specification writer / Implementer in Chromium
    • @kizu, DataDog, Proposer
    • <!-- repeat as necessary, we recommend including group chairs and editors in this list -->
  • Organization/project driving the specification: Google
  • This work is being funded by:
  • Primary standards group developing this feature: CSSWG
  • Group intended to standardize this work: <!-- if different from the current group -->
  • Incubation and standards groups that have discussed the design:

Feedback so far

You should also know that...

No response

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1208

Discussions

Log in to see TAG-private discussions.

Discussed Apr 6, 2026 (See Github)

Matthew: This is interesting. Assigned myself to this during triage, seems nobody else assigned. This is new, haven’t looked at it yet. Will have a look early next week.

Discussed Apr 20, 2026 (See Github)

Matthew: Already looked at this in APA. There are several interesting discussions going in within the CSS WG regarding what the limits of this should be. Combining this with a screen magnifier may also render it too big. Know that they have a similar discussion about the <meta> text-scale feature. APA is working with them. Try to put together a TAG comment as soon as possible. There's a lot of caveats to consider.

Discussed Apr 27, 2026 (See Github)

Matthew: I proposed a draft comment. This is about changing the height of a font so that the text is more justified in the container that it’s in, to make sure lines start and end properly. I have some concerns about edge cases. There is cross-engine commitment. Jeffrey put up a comment that seems to be in agreement with my points.

Ehsan: Had a brief look, but didn’t see any privacy section for this. Skimming through the explainer, I believe it can have potential for fingerprinting, given it’s adaptive to various screen sizes. Would love to see their point on this.

Matthew: Agree that’s worth asking.

Lola: They have an issue about a11y open, and it’s still open. What are your thoughts?

Matthew: Largely good, they have done serious work on it.

Lola: So you would draft a comment related to WCAG, baseline mechanics, …?

Matthew: Yes.

Ehsan: Happy to help.

Discussed May 11, 2026 (See Github)

Matthew: Jeffrey posted a good point on this one (requirements changing in WCAG 3). He suggested that we raise that as a question. Will draft something along these lines. Number of concerns, related to CSS, about growing or shrinking the problem. Ironically, growing the size can turn out to be a problem if you zoom in. I will check to see if there’s anything we’ve got that we can forward to APA. There’s a lot of concern about this. Lots of author consideration required. Not as helpful as what Jeffrey suggested. Will work on a comment.

Hadley: Priorities? Deadlines?

Matthew: Was merged into CSS three weeks ago, we didn’t have long. Guess this is rather urgent. Lots of open issues.

Hadley: As they are asking, we should give them feedback.

Luke: Think merging into a draft with open question seems fine. Seems like this is how CSS works.

Hadley: Seems to be a Chromium thing without a position from Mozilla or WebKit.

Discussed Jun 1, 2026 (See Github)

Lola: skip

Discussed Jun 8, 2026 (See Github)

Matthew: This is the other one I talked about earlier. (…) Would draft something based on Jeffrey’s points. Any concerns, Xiaocheng?

Xiaocheng: No.

Matthew to draft the comment.

Discussed Jun 22, 2026 (See Github)

Matthew: we need to give them some feedabck. This came in a while ago. Basically, I put in a very early draft that could be turned into a comment. Jeffrey wanted something a bit more concrete, but it might be ok. I can see why developers would want this. But this might be something that users might want to toggle this off in the browser. Do TAG members agree with this overall feature? We could take my initial text as a draft... there's some significant a11y issues that have gone quiet, so we could poke them.

Christian: turning it into a comment seems reasonable.

Matthew: there's not mozilla or webkit position yet.

Christian: seems that it's all still in the discussion phase.

For discussion https://github.com/w3ctag/design-reviews-private-brainstorming/issues/263#issuecomment-4797237927

Discussed Jun 29, 2026 (See Github)

Matthew: Another one where I proposed a shape of a comment. Got the impression that everyone except me like this. See the benefit, but I also see why this can be a really bad feature. Recommend that UAs can opt-out of that via a toggle in a11y settings. Seems like introducing non-determinsim to layouting. Wonder how this will affect developer experience. WCAG 3 approach is slightly different. Might make things much harder to read.

Luke: On turning it off, in an ideal world that would be great. In a real world I don’t expect UAs to implement that, similar to interest target and the delays due to observability. Personal opinion is, a11y concern should win. If the feature seems very problematic, we should then rather say that.

Matthew: We could say "don’t make the text too large/too small“, but that might break the feature. Generally, a11y and design don’t have to be in conflict, but sometimes it’s inevitable. We shouldn’t put people in a position where they should trade off a11y with privacy. Will come up with an indication of how it affects (how many) people. It may only be a few, but they may be heavily affected. Worried about privacy issues related to a11y, but this is an aesthetic thing. Might discuss this during a breakout at TPAC. Would love other people’s opinion on this.

Luke: This key bit needs a discussion, it has come up before. Like, "this is our red line," and then we need to stick to this. Guess that’s like CSS grid lanes, which doesn’t see much usage. Is that worth it with the possible harm? Personal opinion is no.