Fix crash with certain right-aligned text

[rparrett]

Objective

Fixes #9395
Alternative to #9415 (See discussion here)

Solution

Do clamping like fit-content.

Notes

I am not sure if this is a valid approach. It doesn't seem to cause any obvious issues with our existing examples.

[alice-i-cecile]

If nothing else, this seems like a safe way to avoid the panic.

I think it may actually be clearer to just do the clamp logic manually, but I won't block on that.

[nicoburns]

Taffy (following how CSS deals with min-width > max-width) does val.min(max).max(min) instead of val.clamp(min, max), which avoids the panic introduced by the stdlib clamp by giving min priority over max. Perhaps we could also do that here?

See: DioxusLabs/taffy#261

[nicoburns]

Hmm... Actually the spec (https://www.w3.org/TR/css-sizing-3/#column-sizing) defines a fit-content size as:

min(max-content size, max(min-content size, limit))

So I think that would be :

x.max(self.info.min.x).min(self.info.max.x)

in the function above

[rparrett]

Okay, thanks for pointing out that spec.

I'll try that out and test with the problematic right aligned text constrained in various ways and see if I can find a difference between us/browsers there just to be sure.

[nicoburns]

This still ultimately seems like a text layout / measurement bug to me. But we should probably do something along the lines of this PR anyway so that we at least don't panic when text layout is returning something nonsensical.

From alexheretic/glyph-brush#167:

There are other cases where glyphs may actually escape these bounds, like a small (or zero) width bound and a larger single word. It is up to the renderer to decide how to handle this, cutting off the glyph as it goes oob or just drawing it oob.

Seems to me that collapsible whitespace ought not to count towards the min-content size. Whereas I would expect a single very long alphanumeric word to extend that size. Not sure if we can implement that.

[rparrett]

I swapped to nicoburns' suggestion of x.max(self.info.min.x).min(self.info.max.x) here.

In my testing I just became less confident that I knew what was going on. It is hard for me to say which bits of the css spec actually apply here. (the "auto box sizes fit-content" section seems to suggest doing the exact opposite thing). I haven't yet figured out what a proper comparison with a browser would even be.

But this should do nothing except in the cases where we would crash previously, so I guess that's an improvement.

[nicoburns]

The CSS spec may be assuming that min-content-size < max-content-size (in which case it doesn't matter which way around you apply the operations). Because it fundamentally doesn't make sense that the size in the "inline axis" (so horizontal axis for horizontal text) when soft-wrapping is allowed would ever be larger than the size when soft-wrapping is not allowed (modulo all other inputs being the same).