[css-values-5] The `<random-value-sharing>` options for `random()` are confusing

[bramus]

I took random() for a spin and must say I struggled quite a bit with the <random-value-sharing> options.

What we have now

As it currently stands, the options are:

• auto: Each random function in an element’s styles will use a distinct random base value.
• <dashed-ident>: Each random function in an element’s styles with the same <dashed-ident> will share the same random base value; ones with different <dashed-ident>s will use distinct random base values.
• element-shared: If element-shared is omitted, random functions on different elements will use distinct random base values.
  If specified, random functions on different elements will share the same random base value if they have the same <dashed-ident> (if specified) or if they’re used in the same style in the same way (if not)
• fixed <number>: If fixed <number> is specified, the <number> is used as the random function’s random base value, rather than allowing the UA to generate a random base value and controlling how it’s shared.

What trips me up

I have a feeling the things are named incorrectly, because:

• The <custom-ident> you use acts like a little cache to hold the value. When reused on an element, it will reused the same value from the cache linked with that element. This makes it a value that is “element shared”, as also mentioned in the title that goes with the example: “Shared by name within an element“.
• element-shared caches the value on a per property base, as made clear in the title that goes with the example: “Shared between elements within a property“. So this isn’t exactly element-shared but more per-property.

Additionally, my first reaction to seeing <custom-ident> would be that this is an identifier that is a global one. But that is not the case. To get that behavior, one must use <custom-ident> element-shared.

How can we fix this?

As mentioned my gut feeling is that <custom-ident> acted as if it was global. I think we should to that and use that as the base. Using keywords, one can then narrow down the scope to per-element or per-property.

So for this example, with 100 of those .random elements:

.random {
  width: random(<caching-strategy>, 100px, 200px);
  height: random(<caching-strategy>, 100px, 200px);
}

You’d get these behaviors for different <caching-strategy> values:

• --foo: The value is cached globally, you end up with 100 identical squares
• --foo per-element: The value is cached per-element, so you end up with 100 different squares
• --foo per-property: The value is cached per-property, so you end up with 100 identical rectangles

The auto case (or no value) would still get you 100 random rectangles.

I’d like to believe that the thing I am suggesting here leads to an easier to understand mental model.

/cc @fantasai @nt1m @jensimmons because I saw this one mentioned in the Safari 26.2 beta release notes.

[nt1m]

We did ask for feedback 4 months ago here: https://webkit.org/blog/17285/rolling-the-dice-with-css-random/ so we could make changes before shipping fwiw. It's too late now for the initial release, but we can probably make changes for upcoming releases if they are appealing enough.

@bramus If I understand correctly, is this your proposal?

Current Spec	New Proposal
.random-rect { width: random(100px, 200px); height: random(100px, 200px); }	.random-rect { width: random(100px, 200px); height: random(100px, 200px); }
.random-rect { width: random(--foo, 100px, 200px); height: random(--foo, 100px, 200px); }	.random-rect { width: random(--foo per-element, 100px, 200px); height: random(--foo per-element, 100px, 200px); }
.shared-random-rect { width: random(element-shared, 100px, 200px); height: random(element-shared, 100px, 200px); }	.shared-random-rect { width: random(--foo per-property, 100px, 200px); height: random(--foo per-property, 100px, 200px); }
.shared-random-squares { width: random(--foo element-shared, 100px, 200px); height: random(--foo element-shared, 100px, 200px); }	.shared-random-squares { width: random(--foo, 100px, 200px); height: random(--foo, 100px, 200px); }

Just to explain the rationale for the current model: it is going from more random to less random as you add keywords. The initially proposed model was going from less random to more random as you added keywords (but we changed that since it was confusing, see #11742), e.g. random() with no key used to just always return the same value globally if used with the same values, which was confusing.

I can understand the appeal of your proposal though it's hard for me to wrap my head around this so I might be missing some use-case or something off in the bigger picture. I'll let @fantasai comment :)

[bramus]

@bramus If I understand correctly, is this your proposal?

Yes, that’s exactly it :)

Just to explain the rationale for the current model: it is going from more random to less random as you add keywords.

It’s not the model but they keywords we have right now that trip me up:

• element-shared actually means per property
• <custom-ident> (when set to the same value) actually means per element
• <custom-ident> element-shared actually means global

… we could make changes before shipping fwiw. It's too late now for the initial release, but we can probably make changes for upcoming releases if they are appealing enough.

The breaking change I see in the current and my proposed list of keywords is that a standalone <custom-ident> would go from a per element behavior to a global behavior. If this breakage is bad (which I doubt), then amending my proposal with a global keyword could help mitigate.

[Loirooriol]

Your proposal doesn't seem to take indices into account, I'm not sure what you expect if random() is used multiple times on the same property.

element-shared means that it's shared among different elements, not within the same element.

Anyways the current spec didn't seem that much intuitive to me either, see #11742 (comment) and #11742 (comment), but that's what was resolved after various discussions.