When I looked at the example 7 in rect() function, the spec says:

The second (right) and third (bottom) values are floored by the fourth (left) and second (top) values, respectively.

And the example 7 is:

For example, specifying rect(10px 0 0 20px) would place the bottom edge higher than the top edge, and the right edge further left than the left edge, so both are corrected to not cross over the other edge, identical to specifying rect(10px 20px 10px 20px).

This seems reasonable. However, we always convert rect() into inset() for the computed values, per spec. So, in the example 7, when we specify rect(10px 0 0 20px), it should be converted into inset(10px 100% 100% 20px) first.

And then, per the spec section of inset():

A pair of insets in either dimension that add up to more than the used dimension (such as left and right insets of 75% apiece) use the CSS Backgrounds 3 § 4.5 Overlapping Curves rules to proportionally reduce the inset effect to 100%.

For example, specifying inset(75% 0 50% 0) has the top+bottom edges summing to 125% of the reference box’s height. They’re proportionally reduced to sum to 100%, identical to specifying inset(60% 0 40% 0).

It uses a different way to handle the case if either dimension of inset() is larger than 100%. So we need to apply the algorithm to make sure we find a factor to reduce 20px + 100%/10px + 100% to 100% or less, for inset(10px 100% 100% 20px). And the result looks different from simply flooring right/bottom values.

I'm wondering should we have to floor the values in rect() at computed time? If not, it seems the sentence of flooring values in rect() looks redundant because we always convert rect() into inset() at the computed time.

BTW, for now all browsers don't floor values of rect() for the computed values. e.g. the computed value of rect(10px 0 0 20px) is inset(10px 100% 100% 20px) (by using getComputedStyle()).