[css-values] random() function

[bendc]

Hi,

I see many authors (myself included) rely on JavaScript's Math.random() to generate a number they can then use to randomize colors, positions, animation delays etc. While it's fairly straightforward to do so (notably with custom properties), a potential random function (or keyword) in CSS would make a lot of sense, especially in conjunction with calc() and friends.

AFAICT @tabatkins proposed something similar quite a few years ago, but I don't think we've discussed it recently, and I think we should reevaluate this option now that we have more context and background on how custom properties and mathematical expressions are being used in CSS.

[emilio]

I don't think random() would make sense. When should it be evaluated? Whenever the style of an element is resolved?

That's right now implementation dependent, there are engines that optimize style changes better than others.

[tabatkins]

In my previous musings on the topic, I stated that there are two ways we can evaluate random(), both of which are useful:

1. Evaluated once per occurrence in the stylesheet, at parse time.
2. Evaluated once per occurrence in the stylesheet per element, at specified-value time.

The first means that .foo:hover { color: rgb(random(0, 255), 0, 0); } evaluates to the same color for every .foo element, and doesn't change if you repeatedly hover/unhover. The second means it'll be different on each .foo element, but will still be consistent if you repeatedly hover/unhover a given element.

There's possibly a third, even less stable mode: evaluated freshly at "application" time, whenever the rule would trigger a transition due to it winning the cascade over a different specified value. This is different per element, and is different each time you hover the element.

---

We'd also want a few different types of randomness; numeric ranges are okay, but getting a random value from a list is very useful and handles colors well, too.

[bendc]

@tabatkins I'm definitely in favor of the third option. Would you mind clarifying what you mean by "getting a random value from a list" though?

[octref]

@bendc Probably like random([1, 2, 4]) when each gets 1/3 probability.

I’d say also provide an option to distinguish between int / float random.

[emilio]

There's possibly a third, even less stable mode: evaluated freshly at "application" time, whenever the rule would trigger a transition due to it winning the cascade over a different specified value. This is different per element, and is different each time you hover the element.

This is not deterministic, right?

[tabatkins]

What do you mean by that?

[emilio]

That the time you apply properties as a result of a style change is not defined, in the sense that engines can do wasted work for that in different ways.

For example, if you have .foo div and you have <div><span></span></div>, adding the class foo to the <div> will cause some engines to re-resolve the style of the <span> and not in others, even though the <span>s style didn't change.

[tabatkins]

That's why I didn't base it on style application, which is indeed undefined, but based it on transition triggering, which is. (The timing is still a little undefined, but assuming you can approach steady state, whether or not a transition occurs is well-defined.)

[emilio]

What do you mean with 'transition triggering'? You mean only resolve random() iff any other style actually changed? You need to resolve the style to know that, so that'd be slow.

[tabatkins]

If a random()-containing declaration would newly apply (such that a transition on the property would trigger, if you treated the random()-containing declaration as being a different computed value from anything but itself), then at that point you resolve the random() to a fresh random value and apply it.

[emilio]

What happens if the OM touches that declaration? Should we re-compute random() to elements that already match it? Such a model sounds complicated to me.

[JamesCoyle]

I think the most logical option from a usage standpoint would be to calculate the random number when a rule is applied to an element. It should only be recalculated if that rule has been removed and then added again (class addition/removal, hover triggered etc).

That would allow for the random value to persist and update controllably rather than in some undefined fashion whenever the browser feels like it and would mean multiple elements targeted by the same selector would receive a different random value. I'm not sure how easy it would be for a browser to implement though.