Re: [csswg-drafts] [css-values-5] The `<random-value-sharing>` options for `random()` are confusing (#13132)

The CSS Working Group just discussed ``[css-values-5] The `<random-value-sharing>` options for `random()` are confusing``, and agreed to the following:

* `RESOLVED: Keep as-is`

<details><summary>The full IRC log of that discussion</summary>
&lt;kbabbitt> fantasai: was looking at what we need to do to implement this in webkit<br>
&lt;kbabbitt> ... made me rethink decision fro a few weeks ago<br>
&lt;kbabbitt> ... random by itself is as random as possible, with an ident scopes it<br>
&lt;kbabbitt> ... until a few weeks ago custom-ident was scoped to element, could use a modifier keyword to share across elements<br>
&lt;kbabbitt> ... new proposal we recently adopted, custom-ident is global shared across elements and can limit with keywords<br>
&lt;kbabbitt> ... reason we got into this discussion was element-shared was a horrible keyword that was confusing<br>
&lt;kbabbitt> ... going through this I thought, maybe we should stick with old proposal and rename keyword<br>
&lt;kbabbitt> ... one reason, more important one, author is less likely to create name clashes if we start with more limited scope and opt into increasing scope<br>
&lt;kbabbitt> ... fully global is very global, you have to come up with a very tight naming system or know you need to use these scoping keywords aggressively<br>
&lt;kbabbitt> ... even if you're doing something simple like getting colors to match<br>
&lt;kbabbitt> ... second reason is webkit is already shipping with what was speced until thismonth<br>
&lt;kbabbitt> ... there's some amount of compat issue, we can break if its worth it<br>
&lt;kbabbitt> ... in terms of intuitiveness, it's not clear to me that being fully global is more intuitive than being scoped<br>
&lt;TabAtkins> q+<br>
&lt;kbabbitt> .. vars for example are per element<br>
&lt;kbabbitt> ... do we think making it fully global is right answer even though it has downsides of likely to create new clashes and needs bralking change?<br>
&lt;kbabbitt> ... in terms of naming, we need to change element-shared to something else<br>
&lt;kbabbitt> ... my suggestion was cross-element because custom-ident is shared across elements<br>
&lt;kbabbitt> ... there's a related issue, while we're thinking about how global we want to be, are we crossing shadow boundaries?<br>
&lt;kbabbitt> ... does random(--foo) in shadow tree interact with same outside>?<br>
&lt;kbabbitt> ... do we need more scoping keywords?<br>
&lt;kbabbitt> ... I think defaulting ot not sharting makes the most sense<br>
&lt;kbabbitt> ... start with limited and add keywords to share across elements, shadows, etc<br>
&lt;Rossen> ack TabAtkins<br>
&lt;kbabbitt> TabAtkins: I think I still want to stick with bramus proposal to have just an ident be maximally global<br>
&lt;kbabbitt> ... for a few reasons<br>
&lt;kbabbitt> ... fantasai, you gave an example of custom prop name for scoping<br>
&lt;kbabbitt> ... reasonable example but it's because custom props are defined on elements<br>
&lt;kbabbitt> ... referencin gthem, element scoping is natural<br>
&lt;kbabbitt> ... other names defined on global level eg font names are not scoped<br>
&lt;kbabbitt> ... not even across shadow boundaries<br>
&lt;kbabbitt> ... when a name is defined globally it's natural for it to be a global reference<br>
&lt;fantasai> Summary of my comment: https://github.com/w3c/csswg-drafts/issues/13132#issuecomment-4171350769<br>
&lt;kbabbitt> ... in this case there's no definition at all, all you're doing is providing an identifier and using it to link things<br>
&lt;kbabbitt> ... to the extent it can be ? it can be understood as a global name<br>
&lt;kbabbitt> ... could assume its scoped but equally good to call it a document global name<br>
&lt;kbabbitt> fantasai: i don't think either is naturally more intuitive<br>
&lt;kbabbitt> TabAtkins: in the absence of a definition defaulting to global is more common in css<br>
&lt;kbabbitt> ... other reason why I like bramus proposal is it gives a consistent direction for how things work<br>
&lt;kbabbitt> ... ident alone gives max randomness, keywords reduces<br>
&lt;kbabbitt> ... otherwise keywords shift in both directions which is a more difficult mental model<br>
&lt;kbabbitt> fantasai: new proposal, keywords make it less random, old proposal keywords make it more random<br>
&lt;kbabbitt> TabAtkins: in the old proposal, everything you add made things less random but that's not part of the spec right now<br>
&lt;kbabbitt> ... in new spec, ident makes global, keyword makes less global<br>
&lt;kbabbitt> ... can make it more random or cross element to make it less random<br>
&lt;kbabbitt> fantasai: suggesting we add cross-element to make it less random<br>
&lt;kbabbitt> ... and if you want property scoped you can put ?<br>
&lt;kbabbitt> TabAtkins: so more change from here<br>
&lt;kbabbitt> ... still really like that a name with no obvious element source being global, makes most sense to me<br>
&lt;kbabbitt> ... same as font face names, cross shadow by default, only one direction to go from there<br>
&lt;kbabbitt> fantasai: whats' going to happen is that best practice for author will be keyword plus scope limiters to reduce number of times they hit this<br>
&lt;kizu> q+<br>
&lt;kbabbitt> ... naming clashes are much more likely to happen without scopes<br>
&lt;kbabbitt> ... have to specify keyword plus names to reduce<br>
&lt;kbabbitt> TabAtkins: amount of specification authors have to do in keyword is identical in both, only difference is whether under current spec you use element-scoped to create element scoping, or escape element scoping<br>
&lt;kbabbitt> kbabbitt: keyword or ident?<br>
&lt;kbabbitt> TabAtkins: I've used them interchangeably<br>
&lt;kbabbitt> ... it's fine either way<br>
&lt;kbabbitt> kizu: from author perspective it's probably what bramus suggests<br>
&lt;kbabbitt> ... where dashed-ident is shared everywhere<br>
&lt;kbabbitt> ... so it's global not very tightly scoped<br>
&lt;kbabbitt> ... if you opt into some scope, it's only the scope you opt into<br>
&lt;kbabbitt> ... collisions while possible only happen if everything else in the random function is the same<br>
&lt;kbabbitt> ... for random function specifically, collisions are not as important noy used across different components things often<br>
&lt;kbabbitt> ... unelss someone using for cryptography<br>
&lt;kbabbitt> ... not important<br>
&lt;kbabbitt> ... need a lot more scoping in css in general but think it sould be explicit if you want to opt in rather than something being very scoped and you have to specify that this specific global scope here, this global scope there<br>
&lt;kbabbitt> ... authors will use same and expect they match<br>
&lt;Rossen> ack kizu<br>
&lt;miriam> I agree with kizu<br>
&lt;kbabbitt> TabAtkins: my preference is to stick with the spec as it is<br>
&lt;kbabbitt> Rossen: can you live with this? any objections?<br>
&lt;kbabbitt> TabAtkins: one objector now defers to kizu and miriam<br>
&lt;kbabbitt> RESOLVED: Keep as-is<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13132#issuecomment-4171665138 using your GitHub account


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

Received on Wednesday, 1 April 2026 17:17:33 UTC