- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 03 Aug 2022 20:11:19 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `random()`, and agreed to the following:
* `RESOLVED: Add random() and random-item(), mark open issues`
<details><summary>The full IRC log of that discussion</summary>
<fantasai> Topic: random()<br>
<fantasai> github: https://github.com/w3c/csswg-drafts/issues/2826<br>
<TabAtkins> https://github.com/w3c/csswg-drafts/issues/2826#issuecomment-1204305712<br>
<fantasai> TabAtkins: This final comment is the current proposal<br>
<fantasai> TabAtkins: idea we've thrown around for awhile<br>
<fantasai> TabAtkins: no urgency, but if ppl like it we can do it<br>
<fantasai> TabAtkins: People have asked for random() function in CSS for a long time<br>
<fantasai> TabAtkins: to use random colors, random positions, etc.<br>
<fantasai> TabAtkins: we've always rejected for good reasons, which is that randomness is stateful<br>
<fantasai> TabAtkins: I believe I have a solution<br>
<fantasai> TabAtkins: and would allow for JS to fill in the remaining use cases not covered<br>
<fantasai> TabAtkins: Proposal aas shown in linked comment is 2 functions<br>
<fantasai> TabAtkins: 1) random() which takes some optional seed params<br>
<fantasai> TabAtkins: low, high, and optionally a resolution<br>
<fantasai> TabAtkins: same output type as math functions<br>
<fantasai> TabAtkins: resolves to <number> between low and high, stepped by resolution<br>
<fantasai> TabAtkins: important bit is the seed param, you can provide a custom ident<br>
<fantasai> TabAtkins: function with same seed and same low/high will always give same seed<br>
<fantasai> TabAtkins: so you can reload and get the same result<br>
<fantasai> TabAtkins: and you can have the same result in multiple pages in the document<br>
<fantasai> TabAtkins: in addition to custom-ident, could give per-element keyword<br>
<fantasai> TabAtkins: which gives a different result per element, but same result on the same element (?)<br>
<fantasai> TabAtkins: second function is similar, but it uses the output as an index into a list of values<br>
<fantasai> TabAtkins: and selects a random one for you<br>
<fantasai> TabAtkins: that's it!<br>
<Rossen_> q?<br>
<flackr> q+<br>
<emilio> q+<br>
<fantasai> lea: if you have custom property from 0 to 1 you can select any value based on custom property<br>
<fantasai> TabAtkins: if you need randomnes that resolves at different times, you can use JS to poke it<br>
<fantasai> TabAtkins: or adjust seed value<br>
<miriam> q+<br>
<Rossen_> ack flackr<br>
<fantasai> flackr: this reminds me an issue with paint API where you want predictable random numbers, so that you wouldn't be exposed to when something is painting<br>
<fantasai> flackr: ...<br>
<fantasai> TabAtkins: that paint API issue is pending a predictable random value in TC39<br>
<fantasai> TabAtkins: but using this, could get a predictable random value in CSS and use that<br>
<fantasai> flackr: but not a bunch of random values<br>
<fantasai> TabAtkins: not an arbitrary number of random values, need API to finish<br>
<Rossen_> ack emilio<br>
<fantasai> emilio: debugging this is going to be fun<br>
<emilio> q-<br>
<emilio> q+<br>
<Rossen_> ack miriam<br>
<fantasai> miriam: As someone who uses a lot of randomness in my styles<br>
<lea> +q<br>
<fantasai> miriam: this would allow me to do that without reprocessing my stylesheet every time i want an update to the randomnes so I really like this proposal<br>
<TabAtkins> fantasai: i think this sounds pretty good<br>
<bramus> thumbs up from me as well<br>
<TabAtkins> fantasai: i like the idea of using custom ident to coordinate without having to use numbers, just let the borwser do it<br>
<Rossen_> ack fantasai<br>
<Zakim> fantasai, you wanted to suggest that index return should be a generic function<br>
<TabAtkins> fantasai: one comment i have right now is random-item(), which has a first argument that returns an index, then a list of items that you select tha tindex from, you might want that to be generic, not specific to randomness<br>
<TabAtkins> fantasai: so you can index into a lit of values with attr() or a variable, etc<br>
<TabAtkins> fantasai: so rather than having a random item function, having something like nth-item() that takes a number and list<br>
<TabAtkins> fantasai: also you probably want to separate th elist with semicolons<br>
<bkardell_> I like what fantasai is throwing down<br>
<fantasai> TabAtkins: that was brought up earlier in the thread<br>
<fantasai> TabAtkins: reason I didn't do that is because then you need to know the lenght of the list ahead of time to know what the random number is<br>
<fantasai> emilio: mod?<br>
<fantasai> TabAtkins: non-uniform results<br>
<fantasai> TabAtkins: also generic function probably doesn't want to mod<br>
<fantasai> TabAtkins: so yes, having nth-item is something we should have<br>
<fantasai> TabAtkins: and it is just slightly too unergonoic to use for randomness, unless we alread add a count method<br>
<bkardell_> q+<br>
<fantasai> TabAtkins: and then you have to either repeat your list or whatever<br>
<fantasai> TabAtkins: a lot of mess for just give me an item from this list<br>
<fantasai> TabAtkins: which I anticipate being reasonably item<br>
<fantasai> TabAtkins: not a strike against nth-item()<br>
<lea> q?<br>
<fantasai> fantasai: If we want the separate, I think we should do them together<br>
<bkardell_> q-<br>
<fantasai> TabAtkins: last point about semicolon. I might. Does mean that syntax that random and random-item is different<br>
<fantasai> TabAtkins: but that might be fine<br>
<fantasai> TabAtkins: yeah, probably fine, probably should do that. I agree<br>
<fantasai> emilio: 1st, what is the syntax for the item in random item?<br>
<fantasai> emilio: tokens?<br>
<fantasai> TabAtkins: <declaration-value><br>
<fantasai> emilio: so just a buch of token<br>
<fantasai> TabAtkins: it's basically variable expansion<br>
<fantasai> emilio: random presumably doesn't work like that<br>
<fantasai> TabAtkins: correct, it's a math function<br>
<fantasai> TabAtkins: we could have them both work at variable time, but making it work as math is a little more useful<br>
<fantasai> emilio: implementation-wise, a lot of stuff relies on being able to filter numbers at parse time<br>
<fantasai> emilio: basically once we're done parsing, translate function<br>
<fantasai> emilio: so implementationwise ...<br>
<fantasai> TabAtkins: already have that problem in calc()<br>
<fantasai> emilio: for raw numbers, yes<br>
<fantasai> emilio: right now impl heavily rely on<br>
<Rossen_> ack emilio<br>
<fantasai> TabAtkins: until you implement calc() per values-4<br>
<fantasai> emilio: if you want this right now, that's where most of the complexity is<br>
<fantasai> emilio: just wanted to mention that<br>
<fantasai> TabAtkins: I'm trying to remember reason why having as a math function is more useful than var<br>
<fantasai> TabAtkins: but I can't quite recall<br>
<fantasai> Rossen_: keep thinking, then<br>
<fantasai> emilio: the seed is not mandatory?<br>
<fantasai> TabAtkins: yes, lack of seed is a seed. It's not arbitrary<br>
<fantasai> TabAtkins: If you say random(1,10) you get same random value ever time<br>
<fantasai> lea: Several things, first I would like to express support. This is amazing. I've definitely used JS for this many times<br>
<fantasai> lea: it would be nice if we could combine and have one function, do we fundamentally need a different one for integers vs ?<br>
<Rossen_> ack lea<br>
<fantasai> TabAtkins: that's literally what we're doing, it returns numbers and there's a step<br>
<fantasai> TabAtkins: look at the last comment<br>
<fantasai> lea: oh!! That's nice!!<br>
<fantasai> TabAtkins: [re-explains why having random-item() rather than nth-item(random()) ]<br>
<fantasai> fantasai: We can have both. nth-item() and random-item() can have parallel syntax and parallel functionality, and both exist<br>
<fantasai> lea: My other points are not relevant anymore then :)<br>
<fantasai> lea: it would also solve a host of use cases if you provide a list of values and get the index back, e.g. have higher-level custom properties and map to other values. Open issue in Web Components for awhile<br>
<fantasai> TabAtkins: unrelated issue<br>
<fantasai> fantasai: what's the computed value?<br>
<Rossen_> ack fantasai<br>
<Zakim> fantasai, you wanted to ask about inheritance<br>
<fantasai> fantasai: if you put it on an inherited property needs to be the same value on every element it inherits through<br>
<fantasai> TabAtkins: not necessarily, if you ???<br>
<emilio> fantasai: if you take line-height to a random value for line-height<br>
<emilio> ... you get a different on each descendant?<br>
<emilio> TabAtkins: it would not, it needs to be resolved to something stable<br>
<emilio> ... if it's a math function it resolves to a number<br>
<emilio> ... otherwise it might resolve later, e.g., if you have a percentage<br>
<emilio> fantasai: is it returning a number or a length / percent?<br>
<emilio> TabAtkins: depends on the argument<br>
<emilio> q+<br>
<emilio> fantasai: needs to be clarified properly<br>
<fantasai> fantasai: so that it inherits properly<br>
<fantasai> emilio: why can't it resolve to a number, and then output resolves later?<br>
<fantasai> TabAtkins: say you want a value between 10% and 50% and step of 100px, how many values is that?<br>
<fantasai> emilio: so like clamp( ... )<br>
<fantasai> TabAtkins: if you clamp, you're non-uniform<br>
<fantasai> TabAtkins: you need to know exactly how many steps between your low and high<br>
<fantasai> emilio: so how would you express that with your proposal<br>
<Rossen_> ack emilio<br>
<TabAtkins> random(..., 10%, 50%, by 100px)<br>
<fantasai> emilio: That's a lot more complex than I was expecting<br>
<fantasai> emilio: you have to keep that function around everywhere wherever you can accept the percentage all the way through calc()<br>
<fantasai> TabAtkins: I think it's why it had to be a math function, to get that to work<br>
<emilio> fantasai: if you restrict it to the same type it you don't have that problem right?<br>
<fantasai> emilio: what fantasai's sying, if you want a percentage random between 50% and 100%, you don't have to wait until used value time<br>
<fantasai> emilio: so as long as you restrict it to the same type<br>
<emilio> TabAtkins: lengths can be computed at used value type<br>
<emilio> fantasai: no?<br>
<fantasai> s/can be/can only be/<br>
<emilio> TabAtkins: for now we've always made sure it's the case<br>
<fantasai> fantasai: lengths are always computable to an absolute length<br>
<fantasai> Rossen_: We're going too deep here. Let's put it in a spec<br>
<fantasai> Rossen_: and then make progress on it<br>
<fantasai> Rossen_: it seems like the group supports this generally<br>
<fantasai> Rossen_: so let's do that<br>
<fantasai> Rossen_: let's try to add this to ...<br>
<fantasai> fantasai: values-5<br>
<fantasai> TabAtkins: I'm comfortable to limiting types, if that ends up<br>
<fantasai> TabAtkins: I'd still be ok<br>
<fantasai> Rossen_: so proposal is to add them and maybe restrict it to numbers?<br>
<fantasai> Rossen_: to CSS Values 5<br>
<fantasai> For the record, I'd really like to restrict this to same type for low/high/step<br>
<fantasai> TabAtkins: The way it's written, you might not get the same result across pages. Might not get same result on reload<br>
<fantasai> dholbert: I hope we can document the algorithm so that it's stable between browsers<br>
<fantasai> TabAtkins: I think that's a great argument that reloads are not stable. But relayout shouldn't be unstable<br>
<lea> q+ to say reloads should absolutely not be stable<br>
<fantasai> lea: I think reloads should absolutely not be stable<br>
<fantasai> lea: if you want a random color for your theme ever time page loads etc, if you get the same thing you might as well pre-compute and be done with it<br>
<Rossen_> ack lea<br>
<Zakim> lea, you wanted to say reloads should absolutely not be stable<br>
<fantasai> emilio: with preprocessors, you can't do the paired element behavior<br>
<dholbert> s/paired element/per-element/<br>
<fantasai> emilio: that said, depending on how this function computes/resolves/etc.<br>
<fantasai> emilio: maybe not undefeatble, but there's a bunch of optimizations that engines have to share styles across elements ...<br>
<fantasai> emilio: it's a bit unfortunate<br>
<fantasai> TabAtkins: alternative is people manually decorate their functions<br>
<fantasai> emilio: harder to do than * { z-index: random() }<br>
<fantasai> TabAtkins: true<br>
<fantasai> Rossen_: any objections?<br>
<fantasai> RESOLVED: Add random() and random-item(), mark open issues<br>
<fantasai> goes into values-5<br>
<TabAtkins> * { position: relative; z-index: random(per-element, 0, 2e9); }<br>
<miriam> ^ this is now considered 'best practice'<br>
<dbaron> next topic is aspect-ratio<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2826#issuecomment-1204425784 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 August 2022 20:11:21 UTC