[csswg-drafts] [css-fonts-5] Text Fitting: Shrinking and Growing (#12887)

kizu has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-fonts-5] Text Fitting: Shrinking and Growing ==
In the [original explainer](https://github.com/explainers-by-googlers/css-fit-text/blob/main/README.md) and in [their prototype](https://docs.google.com/document/d/1qFtLRuZcQN8p4UmMO1n6nLw71MW-93C7CPwS1M6jas4/edit?usp=sharing), Chrome's team proposed to introduce two properties that will handle the “fit-to-width” behavior: `text-grow` and `text-shrink`.

I am strongly opposed to having two properties instead of one, and I wrote about it [here](https://blog.kizu.dev/fit-to-width-discussions-and-feedback/#problems-of-text-shrink). To sum up:

- Having both properties is redundant, as anything you can do with `text-shrink` you could do with `text-grow`.
- If we want to fix the accessibility issue and introduce the default limit (https://github.com/w3c/csswg-drafts/issues/12886), having two properties with their separate limits won't work, as either the limit will need to be too small, or the possible range will become too wide, not solving anything.

In [their feedback](https://github.com/w3c/csswg-drafts/issues/2528#issuecomment-3336857019), Chrome's team states that

> - **Shrinking + consistent (per-block) behavior is essential**: Some web developers emphasized the need for this combination to address long words overflowing their containers.

Thinking about it further, I agree that some use cases want you to approach things by expressing the default font-size, and then allowing it to shrink. While it is possible to implement it with `text-grow`, the resulting code and thought process are pretty awkward.

**My alternative proposal**: what if we had just one property like (name to be bikeshedded) `text-fit`, with `grow|shrink` being the _required_ keyword to use to enable it with the corresponding method — `grow` — do the thing when there is free space, `shrink` — do the thing when content overflows.

Then, the minimal syntax could be just `text-fit: grow` or `text-fit: shrink`, without a need to provide the target, the method, or the limit, relying on their default values.

The original Chrome team's proposal had the `<fit-target> = consistent | per-line | per-line-all` as required. I would propose to use `consistent` as default for `grow` and `per-line-all` for `shrink`, as these seem to be the most useful for each corresponding case.

Reasons for `consistent` being a default for `grow` (I think it is pretty obvious that `per-line-all` is better for `shrink`):
- It works better for more cases, which is demonstrated by the need to have both `per-line`  and `per-line-all`.
- It will be more performant, as we need to only calculate everything for the longest line.
- Non-default values will be easier for authors to write: `consistent` is verbose and prone to typos, `per-line` and `per-line-all` seem to be easier.

List of reasons why I think `text-fit` can be better fit:

- It describes what we do better than `text-shrink` and `text-grow` — if we were to not use `font-size`, but use just `letter-spacing` or something else. Basically “how should it fit?”
- It solves the default size limit problem: 200% can describe “grows up to 200%” or “can be reduced up to 200%”, and we don't need to think about combining the limit.
- It reduces the number of properties and sub-properties that we will need to have: no need to duplicate everything for `text-grow` and `text-shrink`.

Some examples:

```CSS
text-fit: grow;      /* == text-grow: consistent; */
text-fit: shrink;    /* == text-shrink: per-line-all; */
text-fit: grow 250%; /* == text-grow: consistent 250% */
```


Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12887 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 1 October 2025 13:29:03 UTC