Re: [csswg-drafts] [css-fonts-5] Feature for making text always fit the width of its parent (#2528)

Hi everyone,

The Google Chrome team has created [an explainer of the "Fit-width text" feature](https://github.com/explainers-by-googlers/css-fit-text/blob/main/README.md) and [developed a prototype in Google Chrome](https://docs.google.com/document/d/1qFtLRuZcQN8p4UmMO1n6nLw71MW-93C7CPwS1M6jas4/edit?usp=sharing). These were made to start discussions on standardizing this feature.

This article provides our self-feedback on the explainer, based on our experience with the prototype.

# Summary

We should have:
```css
text-grow-target: <fit-target>
text-grow-limit: <length>
text-grow: <fit-target> <length>? (shorthand of the above two)
text-shink-target: <fit-target>
text-shrink-limit: <length>
text-shrink: <fit-target> <length>? (shorthand of the above two)

<fit-target> = consistent | per-line | per-line-all
```

* `letter-spacing` and `word-spacing` should be scaled together with text even if their values are not font-relative.
* `line-height` should be scaled if its value is not absolute.
* Other &lt;length> values should not be scaled even if they are font-relative.<br>e.g. padding of inline elements
* Non-text parts such as inline images and inline-blocks should not be scaled.
* We don't have strong opinions about property names and keywords. e.g. We may rename `text-grow-target` to `text-grow-scope`, and `consistent` to `per-block`.
* We think the feature belongs to css-text, rather than css-fonts.<br>It's similar to the `text-align` property.

# Architecture

Roughly speaking, inline layout has the following steps:
1. Style computation<br>Usually font-relative values are converted to absolute values here.
1. Font shaping
1. Line breaking
1. Line box creation including `text-align`
1. Painting

The fit-width text feature needs to work after line breaking because it needs original widths of lines.  Adding another font shaping step in the fit-width text processing would be possible, but it's hard to add another style computation in it or to restart from style computation.

# Functional Set Content
* **Shrinking + consistent (per-block) behavior is essential**: Some web developers emphasized the need for this combination to address long words overflowing their containers.
* **Handling of the last line**: We should have `per-line-all` in addition to `consistent` and `per-line`. The `per-line` keyword should not scale the last line, and the `per-line-all` keyword should scale all of the lines.
* **Dropping &lt;fit-method> options**:
  * **`Font-size` and `scale` methods**: If we drop the &lt;fit-method> option entirely, the scaling method should be implementation-dependent, and probably it would be either `font-size` or `scale`.<br>These methods produce very similar results, and their differences are likely not significant to most users. In the prototype, the `font-size` method didn't scale `letter-spacing` and `word-spacing`, and the `scale` method scaled them. In order to minimize differences between two scaling methods, `latter-spacing` and `word-spacing` should always be scaled because it's difficult to implement non-scaled `letter-spacing` and `word-spacing` with the scale method.
  * **`Scale-inline` method**: While there are some use cases for `scale-inline` scaling, we don't believe they are numerous enough to include it in the initial standardization.
  * **`Letter-spacing` method**: Defining "`consistent letter-spacing`" behavior proved difficult. For`per-line` scenarios, extending the existing justification feature could cover the `letter-spacing` method. We will remove this from the explainer.
* Existing properties with &lt;length>: Scaling font-relative &lt;length> values is not practical due to implementation complexity. In Chromium, we only have a computed &lt;length> value at the "layout" stage, as a numeric value without unit information. Changing this to retain unit information would increase memory consumption even on pages not using this feature.
The `line-height` property is an exception, as we retain its unit information and can resolve font-relative &lt;length> at the "layout" stage.
* **Conflict with other features**: This feature can alter the block positions of lines, which may cause issues if available space for line boxes depends on those positions. Features like `float`, `shape-inside`, `initial-letter`, CSS Regions, and CSS Exclusions would create such dependencies. We may disable this feature if a container uses these.<br>The desired behavior when a ruby annotation overhangs its ruby base at a line break is unclear. For the initial version, we may disable the feature if a container includes ruby annotations.
* **Performance Considerations**: Concerns were raised about the performance of the `font-size` method, as repeatedly reshaping fonts to find the best fit is impractical. The prototype addressed this with a combination of one-shot reshaping and a scaling transformation.
* **Accessibility**: If the width of a container with `text-grow` or `text-shrink` depends on the viewport width, changing the page zoom level might not alter the physical text size in that container because its physical width remains unchanged.<br>We currently do not have a solution for this issue, and are not sure if the "200% size limit" solution discussed in this issue will work well.

# Property Syntax
* **Two properties for growing and shrinking**: While merging `text-grow` and `text-shrink` is possible, we believe separate properties would offer greater clarity, especially when developers only want either shrinking or growing behavior, or need to specify minimum or maximum font sizes.
* **Shorthand Property*: `text-grow` and `text-shrink` could be shorthand properties, potentially with longhand properties such as `text-grow-target` and `text-grow-limit`.

# Open issues
* Ensuring accessibility of this feature in conjunction with browser zoom remains an open problem to be solved.


-- 
GitHub Notification of comment by tkent-google
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2528#issuecomment-3336857019 using your GitHub account


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

Received on Friday, 26 September 2025 05:44:15 UTC