- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 16:53:34 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values-5] What order to use for the "index of usage" for the default random() keys?`, and agreed to the following:
* `RESOLVED: Mint idents and extend grammar`
* `RESOLVED: Shortest serialization principle will not omit these minted idents`
<details><summary>The full IRC log of that discussion</summary>
<kbabbitt> TabAtkins: this is an in the weeds thing, want to double check with other impls<br>
<kbabbitt> ... spec says if there's no specifier on random() ie maximally random<br>
<kbabbitt> ... one thing included is index of function in random property<br>
<kbabbitt> ... each instance of random gets a distinct value<br>
<kbabbitt> ... question is, how do we determine order?<br>
<kbabbitt> ... detectable due to how we construct the uniquifier<br>
<kbabbitt> ... can see in certain instances random() fns being linked across declarations<br>
<kbabbitt> ... there's a limit to how well we can uniquify before running into issues<br>
<kbabbitt> ... have an example in the issue<br>
<TabAtkins> .foo {<br>
<TabAtkins> box-shadow: calc(10px * random(1, 10)) 10px rgb(255 random(1, 10) 100);<br>
<TabAtkins> }<br>
<TabAtkins> .foo:hover {<br>
<TabAtkins> box-shadow: rgb(255 random(1, 10) 100) calc(10px * random(1, 10)) 10px;<br>
<TabAtkins> }<br>
<kbabbitt> ... in this declaration we have the same property name, same element, 2 random() functions<br>
<kbabbitt> ... they will be tied together in some way<br>
<kbabbitt> ... first to first, second to second, something like that<br>
<kbabbitt> ... however the 2 properties express their values in different orders<br>
<kbabbitt> ... one sets shadow offset first then color, other is the reverse<br>
<kbabbitt> ... question is, to figure out the index and thus linking, do we use order as author wrote?<br>
<kbabbitt> ... i.e. first decl random produces a 3 and so does the second<br>
<kbabbitt> ... or do we link together based on serialization order?<br>
<kbabbitt> ... I have no opinion on which we do, just needs to be specifiied<br>
<kbabbitt> ... proposal based on webkit's initial impl is that we figure out ordering during parsing<br>
<oriol> q+<br>
<kbabbitt> ... so before normalization, any of that, we know what order they appear in and assign index<br>
<romain> q+<br>
<kbabbitt> ... so in webkit, both first instances are link, both second instances are linked, even though they refer to different things<br>
<kbabbitt> ... as far as I know munira is fine with this too<br>
<emilio> q+<br>
<astearns> ack dbaron<br>
<kbabbitt> dbaron: before TabAtkins said the proposal I was going to support that<br>
<astearns> ack oriol<br>
<kbabbitt> +1 to the proposal<br>
<kbabbitt> oriol: this box-shadow property, can be achieved anywhere but could become a shorthand<br>
<kbabbitt> ... how would this play into turning longhands into shorthands?<br>
<kbabbitt> .... when you were saying parsing, before shorthand expansion?<br>
<kbabbitt> TabAtkins: yes that's already part of the spec<br>
<kbabbitt> ... the property name part of uniqufier cares what property it was used on in a shorthand<br>
<kbabbitt> ... so it's already doing a parse level thing<br>
<kbabbitt> oriol: ok<br>
<astearns> ack romain<br>
<kbabbitt> romain: does that mean that roundtripping a value, reading it in JS and setting it changes it?<br>
<kbabbitt> TabAtkins: if you grab computed style serialization and set it back, yes potentially<br>
<kbabbitt> romain: in that case I don't support it<br>
<kbabbitt> TabAtkins: that also happens when using it in a shorthand<br>
<kbabbitt> ... if you read computed value out of longhand and set it back, it's now a change of value<br>
<hoch> q+<br>
<kbabbitt> romain: true but on same property I think it's more suprising but not a strong opinion<br>
<kbabbitt> astearns: it's possible that resetting it would change order but not always<br>
<kbabbitt> TabAtkins: not always, canonical order will remain the same<br>
<kbabbitt> astearns: so in a lot of cases, reading and writing wouldn't have an effect, depends on how value was authorred<br>
<oriol> q+<br>
<kbabbitt> TabAtkins: yes<br>
<kbabbitt> astearns: any follow up romain? alternative?<br>
<kbabbitt> romain: using thing order as serialized value if possible<br>
<kbabbitt> ... seems slightly better<br>
<kbabbitt> ... but only slightly because same issue exists with longhands and shorthands<br>
<astearns> ack emilio<br>
<kbabbitt> emilio: wanted to confirm, per declaration counter?<br>
<kbabbitt> TabAtkins: yes<br>
<kbabbitt> emilio: and not shared<br>
<kbabbitt> TabAtkins: not shared<br>
<kbabbitt> emilio: it's a bit weird to have this hidden state depending on when you parse<br>
<kbabbitt> ... already have that for things like physical values, if you read back out and serialize suddenly you lose information<br>
<kbabbitt> ... alternatives don't seem great, harder to reason about as an author<br>
<kbabbitt> ... somewhat edge casey<br>
<kbabbitt> ... seems fine, not objecting, but maybe should we add a way to serialize back as specified?<br>
<kbabbitt> TabAtkins: very easy, all you have to do is set multiple fns to have different keys<br>
<kbabbitt> emilio: to preserve round tripping should browser serialize with that key><br>
<kbabbitt> TabAtkins: i'd be fine with that too<br>
<kbabbitt> ... think it requires a little addition. to syntax to make it possible grammatically but not a big change<br>
<kbabbitt> emilio: seems maybe worth doing because then it' smore obvious what;s going on<br>
<kbabbitt> ... if you serialize back rand(key) vs rand() you preserve roundtripping which would be nice<br>
<kbabbitt> TabAtkins: given we'd have to record property as well I can just synthesize a --ident for index<br>
<kbabbitt> emilio: for custom props that aren't registered this will eventually go to non custom<br>
<kbabbitt> ... property name would be non custom<br>
<kbabbitt> TabAtkins: yes when it eventually gets parsed<br>
<kbabbitt> emilio: think that would be slightly better because it allows order to be preserved<br>
<kbabbitt> TabAtkins: ok<br>
<kbabbitt> ... proposal then is, add a bit to the spec where if you're using the no argument form of random(), we record the property and index and synthesize a dashed-ident with that information for use in serialization<br>
<kbabbitt> astearns: that would allow authors to either guess at this ident or read it out and provide a connection between 2 different random instances?<br>
<kbabbitt> TabAtkins: they can always link any random instances they like by writing their own key<br>
<kbabbitt> ... not a new functionality, would in theory if authors happen to come up with their own similar scheme, could accidentally clash<br>
<kbabbitt> ... could make names sufficiently unlikely to be used by authors that it's hard to have an accidental clash<br>
<astearns> ack hoch<br>
<kbabbitt> hoch: wanted to clarify, this means if I have a shorthand with a loose ordering rule, that I get slightly different behavior based on order I wrote shorthand in?<br>
<kbabbitt> fantasai: not that behavior will change, that two values will not be identical<br>
<kbabbitt> ... if you change it will trigger a transition because computed values will differ<br>
<kbabbitt> .. will be exactly as random regardless as order<br>
<kbabbitt> hoch: unless I do in 2 places<br>
<kbabbitt> fantasai: they're independent random buckets, you just happened to put them in differen torder<br>
<kbabbitt> ... values changed but still random<br>
<kbabbitt> TabAtkins: if you set values on same style rtule in different order, accidental linkage between them will be between differen tlonghands<br>
<kbabbitt> ... in box shadow for example, color and offset will get linked because fo how you linked 2 definitions<br>
<kbabbitt> ... ideally yuou don't have this linkage, it requires pulling more stylesheet information than needed<br>
<kbabbitt> ... if you'r enot doing this exact corner case you won't notice this detail<br>
<kbabbitt> hoch: I could put in my own ident and just index<br>
<kbabbitt> ... I'd be using that in multiple shorthands in different locations<br>
<kbabbitt> ... what I'd get would depend on how I wrote shorthand?<br>
<kbabbitt> TabAtkins: no, if you provide your own key...<br>
<kbabbitt> hoch: ... asking for index as well<br>
<kbabbitt> TabAtkins: then yes, first things you write in each property with that key will be linked, second will be, etc.<br>
<kbabbitt> hoch: any precedance for loose shorthand having impact?/<br>
<kbabbitt> TabAtkins: no<br>
<kbabbitt> hoch: likely against it but not strong opinion<br>
<kbabbitt> TabAtkins: you can't even do index by itself, always linked to property<br>
<kbabbitt> ... have to use same key in same property across a. bunmch of elements<br>
<kbabbitt> ... and write in a different order each time to seelinkage<br>
<kbabbitt> hoch: that'd be fine, probably doing in same property<br>
<kbabbitt> ... disparate elements using same shorthand, written in slightly different order<br>
<kbabbitt> TabAtkins: you'll have an explicit linkage<br>
<kbabbitt> hoch: [missed] based on whether I wrote shorthands in same order<br>
<kbabbitt> TabAtkins: that's the same as shorthand vs longhand distinction we already have<br>
<kbabbitt> hoch: we have more of those, not sure we have any existing shorthand order actually matters cases<br>
<kbabbitt> TabAtkins: depends how you want to look at that. nothing in css cares whether you set something via shorthand or longhand<br>
<kbabbitt> ... same case inboth instances, but yes it is technically novel being able to tell what order things are in later in the value stages<br>
<astearns> ack oriol<br>
<oriol> https://github.com/w3c/csswg-drafts/issues/8055<br>
<kbabbitt> oriol: roundtripping problem, want to remind of this issue where I proposed from-shorthand function , start drafting somethign<br>
<kbabbitt> ... wouldn't need any special thing to preserve roundtripping<br>
<kbabbitt> ... this proposal is still not fleshed out but would be an alternative<br>
<kbabbitt> TabAtkins: yeah that would work<br>
<kbabbitt> ... it gives it the same functionality as synthesizing an ident, not sure we necessarily want to rely on that, but if we're ok with the serialization potentially changing once we have from-shorthand(), we could defer this problem until we have that feature<br>
<kbabbitt> ... don't have a strong opinion<br>
<kbabbitt> astearns: slightly in favor of more general solution than minting an ident<br>
<kbabbitt> emilio: I think minting an ident is an explainable way to tell what engines are doing<br>
<kbabbitt> ... literally what we're doing, could have used as a key manually<br>
<romain> q+<br>
<kbabbitt> ... don't feel bad about it, tree scopes for example are a lot harder to explain<br>
<kbabbitt> ... don't have a way to serialize<br>
<kbabbitt> ... but in this case it seems pretty doable<br>
<astearns> ack romain<br>
<kbabbitt> romain: proposal from oriol would help but I htink the same problem also exists in longhand properties<br>
<TabAtkins> "margin: random(10px, 20px) random(20px, 30px)", then request `margin-left`, you'd get `margin-left: random(--ua-margin-2 element-scoped, 20px, 30px)`<br>
<kbabbitt> ... longhands with multiple values that be reordered<br>
<kbabbitt> emilio: or values that get duplicated<br>
<kbabbitt> ... specify random() on positioning<br>
<kbabbitt> ... if you need to serialize both then there would be no way to represent that<br>
<kbabbitt> s/positioning/anchor positioning/<br>
<kbabbitt> ... omitting the key and browser building key for you, relatively easy to reason about<br>
<kbabbitt> TabAtkins: that's definitely the shortest path to solution, requires minting nothing new<br>
<kbabbitt> ... at parse time it gains this ident for you<br>
<kbabbitt> astearns: but you have concerns with this entire thing hoch?<br>
<kbabbitt> hoch: not with concept as a whole but choice to do it at parse time instead of normalzied. mild concerns.<br>
<kbabbitt> astearns: we have mild concerns, a path forward that helps with the round tripping as well. should we resolve on doing this ident minting to expose what is we're doing?<br>
<kbabbitt> TabAtkins: I think that's fine<br>
<kbabbitt> fantasai: are serializing for specified value?<br>
<kbabbitt> TabAtkins: yes we have to<br>
<kbabbitt> oriol: so is this ident in addition to ident already provided by author or can they merge?<br>
<kbabbitt> TabAtkins: I think it has to be in addition to<br>
<kbabbitt> fantasai: let's say the ident is index-number<br>
<weinig> q+<br>
<kbabbitt> TabAtkins: what parts of that are variables?<br>
<kbabbitt> fantasai: number<br>
<kbabbitt> ... say I have the size property and it's random<br>
<kbabbitt> ... that expands to random index 21<br>
<kbabbitt> s/21/1/<br>
<kbabbitt> ... random index 1 size<br>
<kbabbitt> ... so author could also themselves write random index 1 size<br>
<kbabbitt> ... author could also write random(sizing index size)<br>
<kbabbitt> ... if they want<br>
<fantasai> size: random() -> size: random(size index-1)<br>
<fantasai> size: radom(size index-1);<br>
<kbabbitt> fantasai: author could also write...<br>
<fantasai> size: radom(foo index-6);<br>
<kbabbitt> ... [more examples]<br>
<TabAtkins> `random(--ua-size-1, ...)` or whatever<br>
<kbabbitt> fantasai: so you're suggesting UA will mint a custom ident based on ...<br>
<kbabbitt> TabAtkins: property and index it's in<br>
<kbabbitt> ... if we want some of this functionality to work we have to mint that hidden information<br>
<kbabbitt> ... only thing we don't need to mint is element id because there's no transporting across elements<br>
<kbabbitt> ... that's just element-scoped keyword<br>
<kbabbitt> astearns: concerns with this?<br>
<kbabbitt> fantasai: feels weird<br>
<astearns> ack weinig<br>
<kbabbitt> weinig: would somewhat prefer that instead of minting an ident, we extend the random() syntax which is currently auto for identifier to be auto identifier and then something new<br>
<kbabbitt> ... like, UA order<br>
<kbabbitt> ... and just have a function that takes a property name and integer and have the UA mint that<br>
<kbabbitt> ... because if people want to use that it's fine but it won't interfere with identifiers<br>
<kbabbitt> ... and clearly indicates what auyto is computed to<br>
<kbabbitt> TabAtkins: fine with that. will need to be in addition to author key in any case, so sure<br>
<kbabbitt> weinig: why an addition?<br>
<kbabbitt> TabAtkins: can provide custom-ident under current spec and then keywords which we're discussin gnext for element-scoped, property-scoped, index-scoped<br>
<kbabbitt> ... that activate hidden information i caching key<br>
<kbabbitt> weinig: gotcha<br>
<kbabbitt> ... ok that sounds fine. some new function that instead of an ident would be preferred<br>
<astearns> ack dbaron<br>
<kbabbitt> dbaron: I think that seems reasonable. If we take that path we have 2 options for seiralization<br>
<kbabbitt> ... one is to always serialize, other is only serialize when needed for roundtripping which would makle it rare<br>
<kbabbitt> astearns: think I prefer the latter<br>
<kbabbitt> TabAtkins: yes per shortetst serialization principlie<br>
<kbabbitt> fantasai: that would mean if, color was first length second, if you put length then color you get this extra key?<br>
<kbabbitt> TabAtkins: yes it would seiralize as randome(-2) and then -1 since it got reordered in canonical serialization<br>
<kbabbitt> dbaron: would also show up in shorthands vs longhands thing<br>
<kbabbitt> fantasai: this is putting a lot into specified serialization that author is not expecting<br>
<kbabbitt> ... seems confusing, especially if you're tyring to read and write serialization<br>
<kbabbitt> ... also puts a lot of emphasis on order of values that otherwise authors don't have to think about<br>
<kbabbitt> ... shouldn't need to know the canonical serialization as an author<br>
<kbabbitt> TabAtkins: you don't need to, if you don't match while using multiple randoms, it will be exposed to you<br>
<kbabbitt> fantasai: I don't think that's a good thing, that we should emphasize to ayuthor it's thw rong order<br>
<kbabbitt> TabAtkins: we're already giving them an order<br>
<kbabbitt> fantasai: sure but that's different than giving them extra stuff<br>
<kbabbitt> astearns: this is trying to fix the problem that there is an observable difference if you rewrite these values<br>
<kbabbitt> ... and are using these different author values<br>
<kbabbitt> ... it's a weird edge case, seem soverengineered<br>
<kbabbitt> fantasai: for this very specific weird edge case, we're going to link creating an observable difference across all properties that's very observable and common<br>
<emilio> q+<br>
<kbabbitt> ... seems like wrong prioritization<br>
<astearns> ack dbaron<br>
<kbabbitt> TabAtkins: I don't care what solution we go to, everything we've discussed here seems okay, just looking for what WG wants<br>
<kbabbitt> dbaron: I think one other way to look at it is, once authors are getting into some of these edge cases, it might have been better authoring practice to write explicit keys rather than have browser figure it out<br>
<kbabbitt> ... I sort of find this okay especially if it doesn't show up much<br>
<romain> q+<br>
<kbabbitt> fantasai: I think this should just be hidden from author, shouldn't have to deal with it in serialization<br>
<kbabbitt> ... where it triggers a difference in behavior, they can fix their order<br>
<kbabbitt> ... doesn't have to match serialization, or do what dbaron said and name stuff<br>
<kbabbitt> dbaron: I would look at it as bad authoring practice but at the same time I think it's less bad to produce a weird serialization than a weird actual result<br>
<kbabbitt> fantasai: don;t think putting color and length in different order in a property that accepts both is a bad authoring practice<br>
<kbabbitt> ... css was designed to make it easy for authors to not care<br>
<kbabbitt> dbaron: my point was about multiple randomes without explicit keys<br>
<kbabbitt> fantasai: ok<br>
<astearns> ack emilio<br>
<dbaron> s/my point was about/what I was calling bad authoring practice/<br>
<kbabbitt> emilio: feels a bit easier to think about as the browser is synthesizing this argument<br>
<kbabbitt> ... then it doesn't feel weird to serialize<br>
<kbabbitt> fantasai: you're a browser engineer, that's why it doesn't feel weird<br>
<kbabbitt> ... author will be like what's this extra junk<br>
<kbabbitt> emilio: better than setting same value and getting different result<br>
<kbabbitt> fantasai: I don't think the behavior is taht different<br>
<kbabbitt> emilio: 2 different random values<br>
<kbabbitt> TabAtkins: can we resolve this with a poll?<br>
<kbabbitt> romain: is it really worse to use order of serialization?<br>
<kbabbitt> ... haven't heard any real downsides or strong opinoins against that<br>
<kbabbitt> dbaron: I have a strong opinion against. Requires running serialization codepath during parsing, or simulating somewhere else<br>
<kbabbitt> ... ton of extra work to figure out serialization order and not normally doing that except when serializing<br>
<kbabbitt> romain: along lines of order shouldn't matter to authors, it is surprising that you get a different value in a different order<br>
<astearns> ack romain<br>
<astearns> ack fantasai<br>
<kbabbitt> fantasai: you're not getting a fundamentally value, just triggering this is a new value and need ot recalc<br>
<kbabbitt> ... if you set style to same exact value as you got from serialization, usually that's not a change<br>
<kbabbitt> ... in this case it recomputes because order is different<br>
<kbabbitt> ... but that's not surprising<br>
<kbabbitt> ... what would be surprising is creating a bunch of extra syntax to expose browser state to authors when they don't need it<br>
<kbabbitt> ... they can use custom idents which are designed for them to control indexing<br>
<kbabbitt> ... shouldn't create a pile of syntax for authors<br>
<kbabbitt> emilio: an extra ident is not a pile of syntax?<br>
<kbabbitt> fantasai: it is though<br>
<kbabbitt> emilio: my understanding is that weinig was fine with ident given it's an extra thing and not interacting with existing ident<br>
<kbabbitt> fantasai: so are we going to serialize every time or only when it doesn't match ordering?<br>
<kbabbitt> emilio: only when it matches<br>
<kbabbitt> fantasai: object to that<br>
<kbabbitt> [missed crosstalk]<br>
<kbabbitt> emilio: maybe 2 randoms in same property should be same thing? that would be weird<br>
<kbabbitt> astearns: suggested to have a poll<br>
<kbabbitt> ... one is let things happen the way they are now, authors will need to fix with own idents<br>
<kbabbitt> TabAtkins: if they hit this odd corner case, values might be linked in a way they don't expect<br>
<kbabbitt> astearns: other option is to mint this ident and extend grammar to show what's going on<br>
<kbabbitt> ... and let things roundtrip without changes<br>
<kbabbitt> astearns: Option 1: close no change<br>
<kbabbitt> astearns: Option 2: do the minting thing<br>
<fantasai> 1<br>
<arronei> 1<br>
<astearns> 1<br>
<romain> 1<br>
<emilio> 2<br>
<castastrophe> abstain<br>
<oriol> 2<br>
<TabAtkins> 2<br>
<ChrisL> abstain<br>
<alisonmaher> 2<br>
<hoch> 2<br>
<lea> abstain<br>
<dbaron> 2<br>
<weinig> 2<br>
<dholbert> 2<br>
<Kurt> 2<br>
<dshin-moz> abstain<br>
<kbabbitt> 2<br>
<kizu> 1<br>
<bkardell> abstain<br>
<Rossen> 2<br>
<cepan> 2<br>
<florian> abstain<br>
<miriam> abstain<br>
<kbabbitt> astearns: ident minting is winning the poll<br>
<kbabbitt> ... unless there are objections we are going to spec out minting the ident<br>
<javierct> 2<br>
<kbabbitt> fantasai: really don't like<br>
<kbabbitt> RESOLVED: Mint idents and extend grammar<br>
<kbabbitt> fantasai: are we serializing it differently based on order?<br>
<kbabbitt> TabAtkins: that is required<br>
<kbabbitt> fantasai: question was, do we drop extra stuff when it's in the correct order?<br>
<kbabbitt> ... which puts strong emphasis on correct order<br>
<kbabbitt> ... changes serialization based on order, I think that puts a lot of unnecessary emphasis on correct order of reorderable syntax<br>
<kbabbitt> ... if we're doing this we should serialize every time<br>
<kbabbitt> TabAtkins: fine<br>
<kbabbitt> emilio: fine<br>
<miriam> I agree with that<br>
<fantasai> fantasai: Authors shouldn't need to think about what the "correct" serialization order is.<br>
<bkardell> I do as well Ithink<br>
<kbabbitt> astearns: Proposed resolution, we will add these minted idents wherever?<br>
<bkardell> 👍<br>
<kbabbitt> TabAtkins: clarify that shortest serialization principle will not cause them to be omitted<br>
<kbabbitt> RESOLVED: Shortest serialization principle will not omit these minted idents<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13337#issuecomment-4171516871 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 16:53:35 UTC