- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 04 Mar 2026 17:06:31 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-values-5] The `<random-value-sharing>` options for `random()` are confusing``, and agreed to the following: * `RESOLVED: Supplying just an ident to the random() function produces a value that is globally shared` * `RESOLVED: add keywords for element, property, and index portions of key, open separate issue for exact names` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> TabAtkins: we have the random function in the spec for a while<br> <kbabbitt> ... have some impl in Chrome<br> <kbabbitt> ... bramus has been chatting with authors and found there's some confusion on options<br> <kbabbitt> ... quick review:<br> <kbabbitt> ... you specify min max and stuff, not important here<br> <kbabbitt> ... important bit is how you control random caching<br> <kbabbitt> ... we can't expose evaluation semantics<br> <kbabbitt> ... we associate each random value with a caching key<br> <kbabbitt> ... as long as caching key is the same, you get same value back no matter how many times you eval<br> <kbabbitt> ... caching key contains property it's on, the index within the property, and some element identifier<br> <kbabbitt> ... these 3 otgether ensure virtually every usage of random() across stylesheet produces a distinct random number, but stable within a page load<br> <kbabbitt> ... can relax this by specifying some caching options<br> <kbabbitt> ... currently there's two of these in a spec<br> <kbabbitt> .. dashed-ident operridves property name + index<br> <kbabbitt> ... element-shared nulls out element identifier<br> <kbabbitt> ...; either of these makes different rand() more likely to be the same<br> <kbabbitt> ... when you use this fn on differen telement with same caching key, will share values<br> <kbabbitt> ... bramus found 2 things that confuse people<br> <kbabbitt> ... first when people used just a dashed-ident, expectation was they were giving random value a name and thus should get same value every time they used it<br> <kbabbitt> ... but as I just specified, that fn still contains an element specific identifier<br> <kbabbitt> ... which violates expectations when a user chosen dashed ident is there<br> <kbabbitt> ... second, people were confused about what access control shared element key did<br> <kbabbitt> ... as specified, random functions on different elements resolve to same thing<br> <kbabbitt> .. expected it to be shared within an element rather than across elements<br> <kbabbitt> ... this is just a bit of an author learning thing<br> <kbabbitt> ... could potentially say they'll learn abot it<br> <kbabbitt> ... but when combined with other issue, there's a reasonable argument syntax is a little confusing and we should rework how we expose random caching to authors<br> <kbabbitt> ... lot of discussion in thread, will hit final bit<br> <kbabbitt> ... rather than the caching options mapping directly to what effects they have on caching key<br> <kbabbitt> ... rephrase whole thing into defining a name for this random value<br> <kbabbitt> ... can specify a dashed-ident and now that's a named random value, same everyhwere<br> <kbabbitt> ... can then mix in additional information into that name to determine dynamicness<br> <kbabbitt> ... using keywords property, element, property-indexc<br> <kbabbitt> ... add an element identifier, property name, etc<br> <kbabbitt> ... making it more unique, less likely to be shared<br> <kbabbitt> ... consistent concept here for first arg, always defining name, names are easy for people to reason about<br> <kbabbitt> ... easier than inverted model of caching keys<br> <kbabbitt> ... do think this will work better for people<br> <kbabbitt> ... seems like it would be decent<br> <astearns> q+<br> <kbabbitt> ... usage in Chrome is still very low<br> <kbabbitt> ... think Safari is early or not quite shipped, okay with changing it<br> <kbabbitt> ... if people are okay with this, we can make edits and get browsers changed to this different model<br> <kbabbitt> q+<br> <kbabbitt> astearns: I like the idea of just supplying the name, making it the most shareable<br> <kbabbitt> ... wondering if we could just start with the ident and not worry about other parts until later<br> <kbabbitt> TabAtkins: can't ignore elements part<br> <kbabbitt> ... if only choices are max random different from everything or min random same everywhere<br> <kbabbitt> ... that kills the use case of share a value within an delement but different elem to elem<br> <kbabbitt> ... theoretically we could avoid prop and index stuff, doable by hand<br> <astearns> ack astearns<br> <kbabbitt> ... just a matter of forcing people to put those sorts of details in by hand<br> <kbabbitt> ... hurts some dynamic use cases especially as we get custom fns() rolled in<br> <kbabbitt> ... would be okay with droppoing those parts for now<br> <astearns> ack dbaron<br> <kbabbitt> ... elem part needs to be in there, core use case<br> <miriam> q+<br> <kbabbitt> dbaron: is plan that not change default behavior when none of the key sturff is specified?<br> <kbabbitt> TabAtkins: correct, nothing specified is max randomness<br> <kbabbitt> dbaron: so is another way to think about default bheavior... my mental model at this point is default behaviors, not specifying a name but are specifying per elem per prop per index?<br> <kbabbitt> TabAtkins: yes, another way to think about it is, if you don't specify anything you get a unique thing<br> <kbabbitt> dbaron: not quite unique because if you override with cascade you can get the same thing<br> <oriol> q+<br> <kbabbitt> TabAtkins: details are slightly differe,t but mental model is with no specified name you get unique name instead<br> <kbabbitt> dbaron: have a slightly different mental model<br> <fantasai> scribe+<br> <astearns> ack kbabbitt<br> <fantasai> kbabbitt: If we're talking about a name in this way, is this something we define with an at-rule instead of instantiating with a property value?<br> <fantasai> kbabbitt: Similar to supports conditions etc. Then have a defined name.<br> <fantasai> TabAtkins: Rejected that idea because it doesn't solve the problem.<br> <kbabbitt> TabAtkins: had to reject that idea becuse it doesn't solve problem<br> <kbabbitt> ... simplest use case could be global, others not<br> <fantasai> TabAtkins: Simplest use case could be global, but others can't.<br> <kbabbitt> ... e.g. per-element values can't be global<br> <kbabbitt> ... doesn't help in any meaningful way<br> <kbabbitt> ...; just introducing a level of indirection that doesn't gain anytrhing<br> <kbabbitt> ... if this was a complicated syntax thing we could offload elsewhere, there might be an argument but this doesn't reduce that<br> <kbabbitt> kbabbitt: ok<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask relationship to table in https://github.com/w3c/csswg-drafts/issues/13132#issuecomment-3562752018<br> <kbabbitt> fantasai: there was a comment from tim that was summarizing interpratations<br> <kbabbitt> ... wanted to check whether what you're proposing is same as what's in that table aside from keywords not having prefix<br> <kbabbitt> TabAtkins: yes<br> <kbabbitt> ... just shortened keywords but it does come down to identical to what tim was proposing<br> <kbabbitt> fantasai: he was repeating proposal, making sure he understood it<br> <astearns> ack miriam<br> <kbabbitt> miriam: hoping I understand correctly<br> <kbabbitt> ... a little confusion from me about when we're matching or sharing a value across elements taht are matched by the same rule<br> <kbabbitt> ... or when are we sharing more globally than that<br> <astearns> match-element?<br> <kbabbitt> ... does element-shared or a name just mean it's shared by all elems matched by that ru;e?<br> <kbabbitt> ... or are we talking about other elems matched by that rule<br> <kbabbitt> TabAtkins: rule it shows up in is not considered at all<br> <kbabbitt> ... arguments to be made that it's intuitive in someways but it's possible without applying a semantic to it<br> <kbabbitt> ... via style rule etvc<br> <kbabbitt> ... don't think tying its randomness to location in stylesheet is sufficiently useful and would often be a trap<br> <kbabbitt> ... so rule location has no bearing<br> <kbabbitt> ... things that matter are property it's used in, index in that property, element it's applied to<br> <dbaron> Tying randomness to rule location makes it hard to do things like "random color, but color-mix() it lighter on :hover"<br> <kbabbitt> ... proposal is supply a name and optionally mix in those identities to make it more unique<br> <kbabbitt> ... anything with same name shartes same value<br> <astearns> ack oriol<br> <kbabbitt> oriol: as I mentioned in issue, not liking the property-index keyword<br> <kbabbitt> ... to me it refers to index within property instead of mix of property + index<br> <kbabbitt> ... also TabAtkins mentioned that allowing a lone index keyword could be weird in practice<br> <kbabbitt> ... that's why we proposed to have keyword as mix of prop + index<br> <TabAtkins> (that is, Oriol prefers `random(--foo property index, 1, 10)` rather than `random(--foo property-index, 1, 10)`, which is fine for me0<br> <kbabbitt> ... guess that's right but from thoretical point of view, having index alone would be totally fine<br> <kbabbitt> ... would prefer to leave the door open to that and have this as 2 keywords<br> <kbabbitt> ... in grammar could require property to be present when specifying index<br> <kbabbitt> ... would at least be easier to generalize in the future if we find it useful<br> <kbabbitt> ... and meaning is clearer<br> <astearns> ack fantasai<br> <kbabbitt> fantasai: overall this makes sense<br> <kbabbitt> ... 2 things that seem strongly intuitive to people are, hjave no args be as random as possible and have a name be globally shared<br> <kbabbitt> ... this proposal hits those while also allowing other variations<br> <kbabbitt> ... lean toward keeping per- prefix, makes syntax clearer<br> <kbabbitt> TabAtkins: argument against that is, wheneve ryou have a relational word like that in keyword, it needs to be clear in context what it's in relation to<br> <kbabbitt> ... 2 opposite things I've seen people read these keywords as relation to<br> <kbabbitt> ... random per element or shared per element<br> <kbabbitt> ... after all the random function name is right there<br> <kbabbitt> ... but function of this argument is to control sharing<br> <kbabbitt> ... people in front of me interpreted in both ways<br> <kbabbitt> ... having that doesn't bias anything<br> <kbabbitt> ... not a strong preference, but preference is to not have that so we guide people to thinking about mixing it into the name<br> <kbabbitt> ... clearer semantic for what I want to communicate<br> <kbabbitt> ... without a relational word in there, more likely to guide authors to correct understanding<br> <kbabbitt> astearns: shall we take a resolution that supplying just an ident is going to make a globally shared random value?<br> <kbabbitt> TabAtkins: yes that's fine<br> <dbaron> +1<br> <kbabbitt> astearns: objections to bare ident case?<br> <TabAtkins> random(--foo, 1, 10) is "globally" shared<br> <kbabbitt> RESOLVED: Supplying just an ident to the random() function produces a value that is globally shared<br> <TabAtkins> (we'll resolve on the exact keywords later)<br> <kbabbitt> astearns: are we ready to make a decision about keywords or should we defer and move to regular meeting?:<br> <kbabbitt> TabAtkins: would be happy to resolve also happy to delay<br> <kbabbitt> astearns: I see a couple options<br> <kbabbitt> ... we could just have a keyword for matching element and others<br> <kbabbitt> ... or could specify all three keywords<br> <kbabbitt> ... not sure index and property keywords are justified by use cases yet<br> <kbabbitt> ... TabAtkins do you have a preference?<br> <kbabbitt> TabAtkins: yes, because those property and index are included in caching key in some cases<br> <kbabbitt> ... we should give option to authors to include them manually<br> <dbaron> +1 to ability to include them -- particularly with the mental model of this that I described :-)<br> <kbabbitt> ... not adding functionality, just a way to flip on in another case<br> <kbabbitt> ... think it's low cost an dpotentially useful<br> <kbabbitt> astearns: why don't we resolve to add property name and index keywords, names to be bikeshedded later<br> <kbabbitt> ... okay with you fantasai?<br> <kbabbitt> fantasai: yes would like to think about names but makes sense<br> <kbabbitt> astearns: any objections to resolving to add keywords for element, property, and index portions of key?<br> <kbabbitt> RESOLVED: add keywords for element, property, and index portions of key, open separate issue for exact names<br> <TabAtkins> happy to continue to have name discussions that we can potentially extra-resolve to, as long as it's relatively quick<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-3998898114 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 March 2026 17:06:31 UTC