Skip to content

[css-fonts-5] Text Fitting: Shrinking and Growing #12887

@kizu

Description

@kizu

In the original explainer and in their prototype, 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. 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 ([css-fonts-5] Text Fitting: Default scaling limit #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, 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:

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions