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

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

== [css-fonts-5] Text Fitting: Scaling of things based on font-size ==
My main point of disagreement with the Chrome team's [feedback](https://github.com/w3c/csswg-drafts/issues/2528#issuecomment-3336857019) is the proposed method of scaling the font.

A few quotes from the feedback where they argue about not scaling any dependent properties or elements based on the change of the font-size, and proposing that it should potentially be implementation-dependent and up to browsers.

<details><summary>Several quotes from the feedback</summary>

> - Other `<length>` values should not be scaled even if they are font-relative.  
>     e.g. padding of inline elements
> - Non-text parts such as inline images and inline-blocks should not be scaled.

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

> - **`Font-size` and `scale` methods**: If we drop the `<fit-method>` option entirely, the scaling method should be implementation-dependent, and probably it would be either `font-size` or `scale`.  
    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.

> - **Existing properties with `<length>`**: Scaling font-relative `<length>` values is not practical due to implementation complexity. In Chromium, we only have a computed `<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 `<length>` at the "layout" stage.

And probably semi-related

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

</details>

---

If I were to sum things up as I understand it: current Chromium implementation converts font-relative values at the Style computation step, so we lose that information when we need to apply the fitting algorithm after line breaking. We can still do so for `line-height` as it retains the necessary information.

I very strongly believe that it will be wrong to do scaling that does not affect the actual font-size and is implementation-dependent with a possibility of just scaling the glyphs and letter-/word-spacing alongside them. For many typographic purposes this will be not enough.

Many fonts have optical sizing variable axis, which is used to adjust various aspects of glyphs based on the applied font-size, improving the readability of the text.

Many elements will need to be scaled alongside the text: things like SVG icons with dimensions defined with `em` come to mind, alongside all the various paddings and margins that use font-relative units and _need_ to be scaled alongside the text.

I have an idea of a proposal, which on the surface, seems to address the issues raised by the Chrome team.

The idea: what if had a new font-relative unit that would _not_ be converted to its absolute value, or could retain the original value in some way before arriving to the text-fitting algorithm?

Then, I see two options:
- For any element with the text-fitting feature enabled, when we calculate styles, instead of converting the font-relative units to their absolute values, we would replace them with this special unit. Then any existent code will continue working as is, without any potential perf regressions, and only code that would add text-fitting will be impacted. Or — could this be done automatically somewhere inside the engine, without exposing this unit to authors at all?
- Don't do the above, and go with what Chrome team proposes by default, at the same time suggesting authors to use this new unit if they want to opt-in some of the places in their code to be scaled alongside the font.

I need to think more about it, but I can see pros/cons for both ways. On one hand, I can see cases where you'd want to keep using the absolute values of original fonts, so having both would be nice. However, I think in most cases authors would want things to scale alongside the change, and we already have tools like registered custom properties that allow retaining the original font-size's absolute value, so, ideally, if possible, this process should be transparent for authors, and “things should just work”.

If the feature were to be implemented as implementation-dependent and without correct scaling of things that depend on the change of the font-size, the feature will be unusable for many cases. Yes, it will cover some of them, but for anything else authors will have to rely on [much more cumbersome and potentially less accessible hacks](https://kizu.dev/fit-to-width/).

And not scaling things like paddings and margins could potentially lead to other accessibility violations for authors, where the spacing between words could become too small, for example.

If we were to make this a standard CSS feature, it should be robust. It is possible to recreate this feature today in a finite number of steps through text duplication — and it does not affect performance of anything else. A native implementation could be only faster, and if it seems that it is impossible now in some of the current engines, we should look for a solution, not discard the feature altogether or trim its abilities to be unusable.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12888 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:32:14 UTC