Re: [csswg-drafts] [css-fonts-5] Text Fitting: Scaling of things based on font-size (#12888)

> Another notable bit is that font shaping is _entirely non-linear_. With common, well-behaved fonts it's usually _nearly_ linear - lay out with twice the font-size, get text approximately twice the length - but absolutely nothing stops it from doing weird and wacky things. […] Fonts are turing-complete programs and can do whatever they want. Even just a simple font-size change can result in having to use a different font for rendering, if it's a bitmap font, resulting in a completely unrelated line length.

In practice, almost no fonts use these non-linear capabilities. Rare edge-cases should not prevent us from solving 99+ common use cases.

Ideally, we should be able to:

- Define a set of constraints in which we can predictably scale the text.
- Outside these constraints, UA can make the best effort, allowed to fully bail out:
 - If the attempt to scale (after all predefined finite steps) results in a _wider_ line than space allows, use the original value.
 - If the attempt to scale results in a _narrower_ line than the original line (which can be the case in reverse `em` calculations for nested elements like `10px - 2em` etc), again, bail out and use the original value.
 - If after the attempt the text grows, but not fit fully into the available space, that should be fine and can be kept as is without further attempts. If that will be contentious, an option like “all or nothing” could be introduced, but I doubt there will be a need for it.

I don't fully the complexity and “guessing” problem, as it is evident that for majority of use cases, including scaling of em-based values and handling optical sizing, we can cover it in a finite number of steps as shown in https://kizu.dev/fit-to-width/ and https://codepen.io/kizu/pen/QwWVXxQ.

If we implement only scaling of glyphs, authors will be confused why something inside the line doesn't scale. The presence of borders, paddings, icons, smaller/larger fonts in a line, where they're _not complex_ and can be covered by a simple algorithm, will happen much more often than any of the edge cases that will result in the algorithm bailing out.

That said, I am not opposed to implementing the glyphs-only type of scaling, but if we do so, we need to do it in a way that won't prevent future experimentation with a proper font-size-based scaling.

For example, if we were to adopt the syntax from https://github.com/w3c/csswg-drafts/issues/12887, then if we were to only implement the glyphs-based scaling, it should be something like

```CSS
text-fit: scale-glyphs grow;
```

Rather than just `text-fit: grow`:

- Basically, we should not choose some values as the default one unless we explore all the possibilities and find out which one is the best. `:has()` was not possible as well, and if one year we will find out a solution for an ideal font-size-based scaling, it would be great to use it by default.
- As mentioned above, the glyphs-only scaling behavior can be confusing if not explicitly stated: mentioning the scaling method will make it more explicit and will communicate to the authors what exactly they can expect.

- - -

So, bottom line: I'm ok with having what I currently see in Chrome Canary (quickly tested on https://codepen.io/kizu/pen/myeRaYE) being available as an explicit fit method from the get go (as long as https://github.com/w3c/csswg-drafts/issues/12886 is covered, as I strongly think we should do it), but I really won't want us to stop at it, and pursue the exploration of a more faithful to the typography and authors' intent method.

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


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

Received on Wednesday, 12 November 2025 05:09:40 UTC