Re: [csswg-drafts] [css-values-5] Maybe min, max and step should not be part of the random-caching-key (#11742)

Closely related issue: I'm trying to make sure that custom properties work in an understandable way, both registered and unregistered.

Unregistered is easy, they're just a little weird. They don't even recognize that a random() function *exists*, so everything about them waits until they're actually substituted - both computation of the default caching key, and resolving the per-element value. A little tricky, but explainable.

Registered properties present an issue, however. They'll see the random(), so they can compute the default caching key based on the custom property. And if the computation is fully resolveable by computed-value time, they can even handle `per-element` based on the element the custom property is applied to. But they're *substituted* as token streams, still, so if the `random()` isn't fully resolved by inheritance time (it contains a %, for example), then it'll remain as `random()` and inherit as such, finally applying `per-element` on the element it's actually substituted into. That's weird! The behavior of `random()` shouldn't depend on its numeric arguments at all, and *double* shouldn't do so *specifically only when used in a registered custom property*!

I could hand-wave some hidden state that has to be carried with it, but I'd prefer avoiding that if at all possible. This suggests that the "random base value" that is computed at computed-value time needs to be explicitly exposed, so that the *computed value* of a random() or random-item() function is *some other, non-random function*, with the random value subbed in.

That is, at computed-value time:

* `random(..., A, B)` *computes to* `calc(R * (B - A) + A)`, where R is the 0-1 random value
* `random(..., A, B, by C) computes to `calc(R * C + A)`, where R is the random int between 0 and however many C steps fit between A and B. (Or to the same as the previous bullet, if the range is big enough and C is small enough that it hits the "just ignore the step" behavior.)
* `random-item(..., A, B, C)` just computes to A, B, or C, as appropriate.

We then rely on normal computed-value behavior from there, simplifying if possible. This would result in an *observable* `calc()` showing up in some cases for the computed value (rather than being either `random()` or a fully-resolved value, as in the current spec).

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


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

Received on Thursday, 6 March 2025 01:15:46 UTC