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

> But not "across elements" dimension. Doesn't seem obvious to me.

Elements are never a dimension addressable from style (only from *selectors*, with careful coordination with your HTML) So if we want to be able to distinguish "shared between elements" and "unique per element" it needs a special-purpose keyword, not something controlled by the author. When element identity is potentially significant in other properties, we similarly handle it with special-case behavior.

And, since we're going with `random(0, 1)` defaulting to "unique per element", we need the keyword to opt you into the opposite behavior (shared between elements). Previously it was inverted - `random(0, 1)` was "shared between elements", and the keyword opted you into the opposite behavior (unique per element).

Having the default behavior be "unique per element" *and* the keyword being "unique per element" is inconsistent. It means leaving off the keyword has opposite behavior depending on *other* values - `random(0, 1)` is unique per element but `random(--foo, 0, 1)` would be shared between elements. That's pretty bad.

It also means there's no way to say "automatically vary by property/index, but match between elements", unless we add more syntax to let you manually opt into that behavior. In your table you glossed over this by instead manually using idents to recreate the behavior, but the point is that there's a useful automatic behavior you get by omitting the ident, and you should be able to get that *regardless* of the independent choice of unique/shared by element.

> It's a matter of whether it's more confusing to have a special behavior for no options which is the opposite of what you would normally expect, vs the inverted model where a keyword implies sharing across all dimensions except (for no immediately obvious reason) across elements.

It is *almost always* the case that omitting something acts consistently regardless of what other values you specify or omit; if we have any exceptions they're super special cases. This extends all the way to "omit everything" when that's possible - this *almost always* gives the same behavior, for each omittable thing, as omitting it. Breaking that pattern should only be done with a *very* good reason.

So yeah, it's way more confusing to have a special beahvior for "no options" which is the opposite of what you'd normally expect.

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


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

Received on Monday, 10 March 2025 18:02:02 UTC