Fit or Stretched Text can not wrap otherwise it does not make sense. But one can have multiple paragraphs on the same container.

We're already adding this rule in block-library. Do we need the redundancy here?

We can remove the redundancy 👍

Ideally, we would avoid this loop and use a direct mathematical calculation. I tried to find a solution but was unable to find one that was reliable in different containers (with or without other fitted children) and that worked across different font families and sizes. Some third-party libraries that use a mathematical calculation rely on the user providing a "compressor" value to optimize how much the text scales, for example: https://github.com/adactio/FitText.js/blob/master/fittext.js.

In the picture, we can see a comparison of our implementation with a third-party implementation using default settings.

What our implementation does is find the largest possible font size that fits in a container without causing scrolling or hiding the text. There doesn't seem to be a direct method that works across various containers and fonts without user tuning. I think, ideally, we should avoid requiring user tuning, even if our code is a little more complex.

Having the loop should not cause a significant performance impact, as we optimize the search using a binary search. In the worst-case scenario, this loop runs only 7 times.

The logic for findOptimalFontSize is contained in a single function, so users don't need to worry about how it works, and if we agree on this approach I will make sure the function is tested with automatic tests.

Should we at least initially try and calculate the size with an offscreen clone of the element to avoid all the layout changes in the visible element? Is this possible or there are restrictions about the parent containers?

Should we look at the first content: 'role' attribute in the schema rather than hardcoded names?

Or perhaps the block supports config could allow optionally specify the attribute key.

The button block might be an example where the attribute isn't the first content role and the attribute is called 'text'. The rich-text type might also be an interesting way to pick the attribute, but then that rules out plain stretchy text.

True. The supports config thing makes sense. Still, could keep role as a fallback, which is IMO better than .content/.value.

I’ve been thinking about this, and I believe we should recompute on any attribute change. Even non-content attributes like padding or margin alter the available space, and a custom block might toggle a boolean that adds a thick border with spacing. In short, any attribute change can affect sizing so recomputing on every change seems the safest and simplest approach, on #71904 we were reconputing on any attribute change of the descendent of the group block (getBlocks() changed), here I tried to optimize but I don't think it was a good idea.

None of the callers of optimizeFitText use the return value. Discard?

Yes it was discarded 👍

If we inline this function, we'll improve a few things:

• it becomes evident that getOriginalFontSize's codepath for a falsy textElement is never run
• the side effect applyStylesFn( '' ) is made more prominent (the function name starting with get is a bit misleading)

Also, there a lot of superfluous comments in this file.

Makes total sense this logic was simplified we don't even need to retrieve explicitly the original font size.

I understand wanting to encapsulate this in a function, but don't export it unless needed.

The idea was to export so it can be imported on the tests file. But until tests we don't need the export so it was removed.

Range (–200) doesn't correspond to actual constants (600).

It was 200 before I updated the comment to match the new value.

We're already adding this rule in block-library. Do we need the redundancy here?

Nit: this should already be a boolean, right? Why the cast? Same question for checked={ !! fitText } below.

Fixed 👍

Why not just a counter living in the module? Also, typo in the comment.

(I know the odds are next to nil, but playing dice with Math.random() and not checking for collisions makes me uncomfortable 😆)

Right a counter works well here, it was simplified.

Not needed.

I suppose that if you wanted to be extra careful you could .disconnect the observer if element no longer exists.

Removed.

Don't forget to check if true

Switched to empty which checks for false.