[css-values-5] What order to use for the "index of usage" for the default random() keys?

[tabatkins]

If you don't specify a dashed-ident in the caching key for random(), one is auto-generated for you using the property name and the index of the random function among other random functions in that value. For example, border-width: random(0px, 10px) random(10px, 20px);, it's equivalent to writing border-width: random(--bw0, 0px, 10px) random(--bw1, 10px, 20px);. This ensures that two random() functions in a value aren't accidentally linked, but also that when a shorthand implicitly repeats a value, it'll use the same value.

However, the spec doesn't specify exactly what this "order of appearance" is. It appears that Safari uses the order of appearance in the specified value, while Blink uses the "normalized" order that would result from serialization.

For example, given the following styles:

.foo {
  box-shadow: calc(10px * random(1, 10)) 10px rgb(255 random(1, 10) 100);
}
.foo:hover {
  box-shadow: rgb(255 random(1, 10) 100) calc(10px * random(1, 10)) 10px;
}

If you hover and unhover the element, do you see a change or not? In Safari you see a change - if the first style generates numbers 3 and 7 (creating 30px 10px rgb(255 7 100), then the second style will swap what those 3 and 7 are used for (creating 70px 10px rgb(255 3 100)). In Blink there's no change.

I don't have much an opinion on which we should go with - linkage across declarations is accidental and not meant to be depended on. So I think it's just what is more natural for implementations. Thoughts?

/cc @tursunova and I think @nt1m ?

[nt1m]

cc @weinig @fantasai if they have thoughts

[tursunova]

Property dependent random() behaviour is not yet fully implemented in Blink, therefore you can't currently see the change in the test. I don't have a strong opinion on which behaviour would make more sense here at the moment.

[weinig]

Not that implementation rationale should drive the end design, but the reason for the behavior in WebKit is that we assign the identifiers during parsing (the calc parser stores the property name and number of random() functions seen so far while parsing this property). Needing to assign identifiers after parsing would be quite a bit more complicated for us.

That said, this example makes me wonder if we should add pseudo-classes (or no pseudo-class for the standard case) to the tuple used for auto, since at first blush, I would not have expected the two styles in the example to share at all.

[tursunova]

Blink should also be using specified value's order of appearance for random() caching index now. Since there wasn't anyone against it, maybe we can async resolve to use the order of appearance in the specified value for random() caching?