- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 26 Mar 2025 16:33:08 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-values-5] Maybe min, max and step should not be part of the random-caching-key`, and agreed to the following: * `RESOLVED: Accept the proposal for changing random caching as stated in the issue.` * `RESOLVED: Go with element-shared for now, keep renaming issue open because many people are unhappy with it` <details><summary>The full IRC log of that discussion</summary> <dholbert> ScribeNick+ dholbert<br> <fantasai> scribe+<br> <fantasai> TabAtkins: The random() functions currently, by default, are maximally random.<br> <fantasai> TabAtkins: two axes controlling how they resolve<br> <fantasai> TabAtkins: 1. Which property they're in, and what index in the declaration<br> <fantasai> TabAtkins: 2. whether same across all elements or different<br> <fantasai> TabAtkins: can change either of these<br> <fantasai> TabAtkins: Force same across properties/instances by applying custom ident<br> <fantasai> TabAtkins: or force same across elements by using special keyword<br> <fantasai> TabAtkins: some opposition from oriol about the way that the element sharing was phrased<br> <fantasai> TabAtkins: He preferred previous model where elements shared by default, and opt out<br> <fantasai> TabAtkins: Since then several people commented preferring that starting with maximal randomnes is better<br> <oriol> q+<br> <astearns> ack oriol<br> <fantasai> TabAtkins: so my proposal is to adopt the proposed model, and then address naming quesiton<br> <fantasai> oriol: My concern is that when you provide the keyword, not clear that you would share across instances but not across elements<br> <fantasai> oriol: In our other properties with custom elements, you get same behavior for same custom ident<br> <fantasai> oriol: I worry it could create some confusion<br> <fantasai> oriol: But I think if you provide random() with no parameter, maximizing randomness is better<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: one option is that "no parameters" is maximum randomness, using a custom ident gives you global correspondence, and using custom-ident+a keyword gives you shared in an element, but differetn across elements<br> <fantasai> TabAtkins: Yes, that would be a "per-element" keyword, discussed already<br> <fantasai> TabAtkins: I don't like that because it breaks independence of omitted chunks<br> <fantasai> TabAtkins: omitting all params shouldn't be different from the behavior of omitting each individually<br> <fantasai> TabAtkins: We usually adhere to that model, so I prefer to stick to that model.<br> <fantasai> TabAtkins: Specifying peels back specific aspect of randomness.<br> <fantasai> TabAtkins: rather than doing an inversion as soon as you specify anything<br> <fantasai> fantasai: I don't mind either way, just saying this is another possible syntax model.<br> <fantasai> astearns: so should we resolve on this model of maximal randomness?<br> <fantasai> RESOLVED: Accept the proposal for changing random caching as stated in the issue.<br> <fantasai> TabAtkins: We need to name the share-randomness-across-elements keyword<br> <fantasai> TabAtkins: some options were `element-shared` and `all-elements` ... other suggestions in issue<br> <fantasai> Proposal is at https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2707697957<br> <fantasai> [this should go into the resolution]<br> <fantasai> astearns: Do we have existing keywords related to this idea?<br> <bramus> q+<br> <fantasai> Suggested keywords https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2708387121<br> <astearns> ack bramus<br> <astearns> ack fantasai<br> <bkardell_> +1<br> <TabAtkins> fantasai: I think I agree with tim on match-element being confusing, it doesn't really convey... we're not matching this value to this element, liek it does in VT<br> <TabAtkins> fantasai: it's "this function should match across all elements", different concept<br> <bkardell_> thisfunctionshouldmatchacrossallelements<br> <TabAtkins> astearns: should we resolve on 'element-shared'?<br> <TabAtkins> fantasai: element-shared sounds weird<br> <bkardell_> I think I disagree all elements sounds more obv<br> <TabAtkins> straw poll: 1) element-shared, 2) all-elements, 3) both of these suck, i have a better idea<br> <TabAtkins> 1<br> <schenney> 1<br> <ydaniv> just "shared"?<br> <astearns> 1<br> <bkardell_> 1<br> <Kurt> 1<br> <fantasai> 2, but I wish I could pick 3<br> <miriam> 2<br> <alisonmaher> 1<br> <bramus> 1<br> <ydaniv> 1<br> <oriol> Maybe 3) shared-across-elements? Or 2)<br> <vmpstr> (abstain)<br> <kizu> 2<br> <dbaron> 1 (weakly)<br> <dbaron> (what about across-elements?)<br> <fantasai> +1 dbaron<br> <oriol> Not clear if across-elements is varying across elements or caching across elements<br> <kbabbitt> match-across-elements ?<br> <fantasai> fantasai: match-elements ?<br> <fantasai> TabAtkins: too close to v-t-n: match-element<br> <fantasai> ydaniv: by-property?<br> <dholbert> (I'm not particularly enthusiastic about either of the options but I don't have a better suggestion )<br> <emilio> (same as dholbert)<br> <fantasai> PROPOSED: Go with element-shared for now, keep renaming issue open because we're all unhappy with it<br> <fantasai> RESOLVED: Go with element-shared for now, keep renaming issue open because many people are unhappy with it<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11742#issuecomment-2755039081 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 26 March 2025 16:33:10 UTC