Re: [csswg-drafts] [css-values] Proposal: `round()` to a finite scale (#11067)

This use-case sounds potentially useful. I'd be willing to spec this if the WG thinks it's worthwhile.

* Yeah, duplicates should be fine. There is indeed no reason to have a single-item finite scale; that's equivalent to just clamping.
* Sorting or not is actually interesting. If we sort, then two values that are expressed in different units might exchange position, if the two units don't scale equally. That may or may not be what the author intended. If we don't sort, we presumably handle misordering the same way that gradients do, by bumping the later one in the list up to the position of the earlier one.
 
 Whether we sort or not, tho, simple cases can be swapped to the other semantic with strategic use of min()/max(). Tho I suppose defaulting to sorting is easier to handle slightly more complex cases; you can regain the gradient behavior by changing, say, `A B C` to `A max(A, B) max(A, B, C)`; repetitive but doable. If we default to gradient behavior, tho, regaining the sorting behavior is a lot more complex; I think the simplest way to sort `A B C` is `min(A, B, C) calc(A + B + C - min(A, B, C) - max(A, B, C)) max(A, B, C))`, ugh, and it gets worse with 4 values.

I do think it's probably worth putting this under a new function name, rather than reusing round(); this is *kinda* rounding but not quite, especially if we allow ranges where the value is unchanged. This also avoids us having to be consistent with round() for the `round(down, 0, 2 3 5)` case - we can just say that this resolves to 2, and you can manually use `-infinity` if you want.

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


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

Received on Tuesday, 22 October 2024 21:18:23 UTC