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

A few more experiments and further thoughts about the limitations of my technique and a potential algorithm based on it.

The main limitation will be that while it works well for a singular relative font-size, it won't be as good when there are nested elements or aspects that use static values or complex calculations.

- If there will be values in `px`, they will break the scaling, as we no longer could scale things proportionally.
 - It could be possible to work around this with my technique by adding _yet another_ copy of the text. With it, we'd reduce the font-size to `0` and measure the result, getting the remaining static width that could be subtracted from any further calculation for the scaling.
 - With the browser algorithm, it could also be something that should be possible to implement: either in the same way, rendering things with 0 for any relative units, then subtracting it from the further calculations. Or maybe there could be further optimizations: if, when rendering things, we know that some values, that result in the increase in the inline direction, are static, we could account for them in our calculations without an extra render.
- If there are values in `em` like `0.5em` or `1.5em` on nested elements, things will still scale well, except for the optical sizing, as we will make it static, approximating on the font-size of the original element.
 - I am not yet sure if there is an easy workaround for this, but maybe? I am not sure if it is possible to achieve in my technique, as we can't easily retrieve the font-sizes of the inner elements to approximate their `opsz` axis, but a native implementation could achieve this easier: when we render the intermediate approximate state, we'll fix the optical sizing for all the participating elements before further scaling.
- The most problematic case: mixed units like `calc(0.5em + 10px)`, or font-sizes with `clamp()`.
 - I don't think there is any venue to accommodate them: they result in a non-linear scaling, each being a new variable, making things much more complicated.
 - That said, in my testing, while the results are not good (text does not scale properly), not solving this edge case sounds like a good enough compromise. These kinds of dynamic units are generally used for other attempts at making the text scale to the container, and there is much less need for them inside the text that fits the container via a native feature.
 - Given the final result will still use the original font-size as the minimal fallback, it should be acceptable to not get the proper scaling for this edge case.

While these findings complicate the final algorithm a bit (accommodating the static dimensions + a per-element optical sizing freezing), and uncover cases that won't scale perfectly (mixed units and calculations), I still think this algorithm is a viable step forward.

With things like `text-wrap: balance` we already incorporate some compromises, preferring to cover the most common cases, and when approaching the text scaling we could do the same.

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


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

Received on Wednesday, 28 August 2024 10:09:57 UTC