- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 31 Jan 2025 17:29:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-cascade][css-syntax] New `!revertable` flag to mark a declaration as "can be reverted when IACVT"``, and agreed to the following:
* `RESOLVED: Add revert-rule as a css-wide keyword`
<details><summary>The full IRC log of that discussion</summary>
<ntim> lea: instead of having declarations override other declarations when they are IACVT<br>
<oriol> q+<br>
<ntim> lea: this would allow declarations to revert<br>
<emilio> q+<br>
<ntim> lea: make it like they didn't exist, which is very useful for if()<br>
<ntim> lea: this is the last piece for making it work properly<br>
<ntim> lea: we have style queries/if() functions, this last piece gives us conditionals that can be rolled back<br>
<ntim> lea: the more we add IACVT things to the language, the more useful it is<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to react to lea to explain this in a different way<br>
<dbaron> Wiktionary says revertible is a more common spelling than revertable. (I'm also a little hesitant about the name because I think people will have trouble spelling it.)<br>
<dbaron> Otherwise I like the idea.<br>
<lea> s/ this is the last piece for making it work properly/ this is the last piece for having conditionals in CSS, but it's also useful for anything that does IACVT/<br>
<lea> q+<br>
<miriam> q+<br>
<ntim> fantasai: if you have a bunch of invalid things, we need to make it revertible, instead of falling back to the previous declaration<br>
<ntim> lea: this behavior should have been the default in the past<br>
<ntim> lea: it's a pain for authors<br>
<ntim> lea: an opt-in makes it very intentional<br>
<astearns> ack oriol<br>
<fantasai> s/if you have a bunch of invalid things/if you have things that can become invalid at computed value time, rather than at cascade time, then when it becomes invalid you have to fall back to a default value rather than to the previous declaration in the cascade./<br>
<fantasai> s/we need to make it revertible/Lea's proposal is to flag such declarations to request that the previous declaration in the cascade be cached, so that you can fall back to it if the !revertible declaration becomes invalid/<br>
<ntim> oriol: I don't like a !revertible flag for this because the way you are block, the indexing of the block is that you have an ordering, and each property has value.<br>
<ntim> oriol: if we were only reverting within the same property, we could shift down declarations for the same property<br>
<lea> I don't understand the issue, perhaps an example could help?<br>
<fantasai> s/instead of falling back to the previous declaration/just as if it had become invalid during the cascade/<br>
<ntim> oriol: we could shift everything down to the last declaration for the last property<br>
<ntim> oriol: since we have cases where different properties share properties, like logical properties.<br>
<bramus> scribe+<br>
<bramus> oriol: strongly thingk that here we should have the same reverting behavior that reverts within props that share the computed value<br>
<bramus> … and then this implies to keep track of the value declarations and they could be interleaved<br>
<bramus> … and we would need to keep trackt of that in order to revert propertly<br>
<bramus> … deos not work with how CSSOM exposes these<br>
<bramus> … and how its implemented<br>
<bramus> … isntead of a flag, this hsould be a new at-rule<br>
<bramus> … @revertible selector<br>
<bramus> … that would not assume you have a single value for each prop to allow ??? with differnent indexigin<br>
<bramus> … in the issue lea argued against this asahying it would make it easier for authors to opt in and bad for perf<br>
<bramus> … dont agree that making things harder is ??<br>
<bramus> … its backwards<br>
<bramus> … an atrule could be better<br>
<astearns> ack emilio<br>
<bramus> emilio: big +1 to the counterpoints oriol made<br>
<bramus> … this would really complicate how css is exposed in CSSOM and other details<br>
<bramus> … but i have an idea that might work<br>
<bramus> … seems to me that what you want is fallback within same decl block and that is problematic<br>
<bramus> … and fallback within separate decl blocks<br>
<bramus> … with revertable you revert as in some new kind of revert unlike the revert keyword<br>
<bramus> … feels like 2 features<br>
<bramus> … 1 could be a csswide keyword that says ignore<br>
<bramus> … a nice way to represent this would be a top level value function<br>
<bramus> … you would do border-radius: var(--width);<br>
<bramus> … you’d try a list of values instead with a function<br>
<TabAtkins> qq+<br>
<bramus> … and none of them parse then the decl gets ignored<br>
<bramus> lea: sounds like first-valid<br>
<lea> q+ to say this does not address use cases at all<br>
<bramus> TabAtkins: with the addition of that wipe keyword<br>
<dbaron> s/wipe/CSS-wide/<br>
<bramus> emilio: that would achieve what you want<br>
<bramus> TabAtkins: i thkn it does<br>
<bramus> emilio: no need to repeat property name<br>
<lea> q?<br>
<bramus> … and more consistent with everything else<br>
<TabAtkins> ack<br>
<TabAtkins> q-<br>
<dbaron> So I think emilio is proposing try(value1, value2, ignore)<br>
<ntim> emilio: I think it addresses it in a less verbose way<br>
<emilio> right<br>
<oriol> q+<br>
<bramus> lea: oh, that would bake it into first-valid<br>
<bramus> TabAtkins: i gues sthe keyword is not usseful ouside of first-valid<br>
<bramus> lea: it is<br>
<bramus> … more useful than the function<br>
<bramus> … you can have expressions that output the keyword<br>
<bramus> … sounds better<br>
<bramus> … its like revert-declaration<br>
<bramus> … can we do that?><br>
<bramus> emilio: i think so<br>
<oriol> This is https://github.com/w3c/csswg-drafts/issues/5319<br>
<bramus> … at least more easily than what you proposed<br>
<bramus> lea: its even better<br>
<bramus> astearns: lets go to the queue<br>
<bramus> TabAtkins: emilio, is that only easier at parse time?<br>
<bramus> emilio: no, should work fine at computed value time<br>
<bramus> TabAtkins: how would you treat it as if it has never been said?<br>
<bramus> emilio: when apply decls … so revergint is ???<br>
<bramus> TabAtkins: i see, you have a full cascade list<br>
<lea> s/lea: its even better/lea: if we can actually do that, that is even better!/<br>
<dbaron> s/revergint is ???/reverting is just keeping going/<br>
<bramus> emilio: and you already have that for revert-layer<br>
<bramus> TabAtkins: thought that ws simpler<br>
<bramus> lea: will that work if you have a diffrent decl for the same prop in the same rule<br>
<bramus> emilio: no<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to say this does not address use cases at all<br>
<bramus> lea: so like revert-rule then<br>
<bramus> … love this<br>
<bramus> … amazing<br>
<bramus> … lets piggy back on revert-layer for the name<br>
<astearns> ack miriam<br>
<dbaron> lea: ... and call it something like revert-rule<br>
<bramus> miriam: emilio’s proposal solves all my issues with this, i like it<br>
<bramus> emilio: naming is chosen by ?? – open to any naming<br>
<astearns> ack dbaron<br>
<emilio> s/??/jet-lagged emilio/<br>
<bramus> dbaron: issue that i was gonna raise that i felt i need a diff between in-rule and across-rule behavior<br>
<bramus> … but if name is revert-rule that is addressed<br>
<TabAtkins> so, replacing the issue example<br>
<TabAtkins> <br>
<TabAtkins> animation: if(style(--effect: grow), 1s grow) !revertable;<br>
<TabAtkins> animation: if(style(--effect: pulse), 4s pulse infinite) !revertable;<br>
<TabAtkins> <br>
<TabAtkins> with<br>
<TabAtkins> <br>
<TabAtkins> animation: if(style(--effect: grow): 1s grow; style(--effect: pulse): 4s pulse infinite; else: revert-rule);<br>
<bramus> … the revert-rule name cleverly addresses that confusion<br>
<astearns> ack oriol<br>
<bramus> oriol: i expressed earlier concerns about messing with the data structures of how rules are stored in impls<br>
<bramus> … adding a keyword was proposed in another issue before<br>
<bramus> … support it<br>
<bramus> … its already implemented that in fallback values hwere you use revert-layer<br>
<bramus> … could auto0-wrap without forcing all this<br>
<bramus> … it convenient<br>
<dbaron> And the proposal seems to be to use https://www.w3.org/TR/css-values-5/#first-valid<br>
<bramus> astearns: do we have a proposed resolution?<br>
<bramus> emilio: dont know status of first-valid<br>
<bramus> emilio: resolution wuold be to add a new revert-rule css-wide keyword that reverses to the previous declaration in any rule (not within cascade layers)<br>
<bramus> dbaron: in a different rule<br>
<bramus> emilio: right<br>
<astearns> ack fantasai<br>
<bramus> fantasai: so a rule is selectr { decls }<br>
<bramus> … so woul dyou revert entire block, or only the 1 prop?<br>
<bramus> TabAtkins: 1 prop<br>
<bramus> fantasai: so only that prop bu tout of tha tentire block of decls<br>
<bramus> emilio: yes<br>
<bramus> … conceptullay there is no order decl for tha tprop in that block<br>
<bramus> fantasai: yers<br>
<bramus> s/yers/yes<br>
<kizu> q+<br>
<bramus> fantasai: makes sens<br>
<ntim> I think TabAtkins' example illustrates it somewhat well:<br>
<ntim> animation: if(style(--effect: grow): 1s grow; style(--effect: pulse): 4s pulse infinite; else: revert-rule);<br>
<bramus> … but thye cant do it in same block<br>
<bramus> emilio: but can use first-valid for that<br>
<oriol> q+<br>
<bramus> TabAtkins: yes, already have first-valid that covers this<br>
<bramus> fantasai: so you”d always have to wrap the decl value in first-valid<br>
<bramus> TabAtkins: or use if()<br>
<bramus> lea: can we make first valid work like that by default?<br>
<bramus> TabAtkins: would prefert not. usually to be explicti when doing this stuff<br>
<lea> q+ to ask, can we have a function that works like first-valid() but has this fallback automatically<br>
<bramus> fantasai: this si gonna be author-to-author - you are not gonna creata this list. overhead when using first-valid to attach the keyword at the end is not ergonomic<br>
<bramus> … other than that it seams reaosnable<br>
<lea> +1 to fantasai. I missed what the reason to always wrap in a function is?<br>
<bramus> emilio: would choose a different name for the fn, maybe try<br>
<bramus> fantasai: its the fact that you need to use the fn, not the keyword<br>
<bramus> emilio: syntactic overhead is already there<br>
<bramus> fantasai: what if you did !try<br>
<bramus> emilio: then you have the same cssom issues<br>
<bramus> fantasai: would behave as if you wrap it in first-valid<br>
<astearns> qq+<br>
<fantasai> foo: first-valid(stuff, revert-rule); -> foo: stuff !try;<br>
<bramus> emilio: think i misunderstood – so elika is saying that !try implitcly wraps it i first-valid(…, revert-thing) by itself<br>
<bramus> … its less obvious when you have<br>
<bramus> … if i use !try , ’d expect reverting to prev decl<br>
<bramus> fantasai: i’m saying its a lot to write with first-valid + keyword<br>
<lea> Another downside with this approach is that it's less composable. Often values are composed from other variables, now every point of usage needs to know about this<br>
<bramus> … does not require much syntactic structure to this<br>
<bramus> … authors woul duse this a lot i think<br>
<bramus> astearns: can add the short name in the future<br>
<astearns> ack astearns<br>
<Zakim> astearns, you wanted to react to fantasai<br>
<astearns> ack kizu<br>
<astearns> s/short name/short syntax/<br>
<bramus> kizu: should work in first-valid, else would need to work as fallback for custom props<br>
<bramus> … only chrome handles css-wide keywrods in custo m props properly i think<br>
<kbabbitt> s/else would need/also would need/<br>
<bramus> … !try as syntax sugar would be nice to have as well<br>
<astearns> ack oriol<br>
<bramus> oriol: i recall that tab strongly saying that first-valid should only check parse validity, not the computed values<br>
<bramus> … do we change first-valid then?<br>
<bramus> TabAtkins: dont recall that, let me check<br>
<bramus> … if thats the case then we use a diff fn or change first-valid<br>
<astearns> ack lea<br>
<Zakim> lea, you wanted to ask, can we have a function that works like first-valid() but has this fallback automatically<br>
<bramus> lea: why did we conclude that we need to wrap in fn?<br>
<bramus> TabAtkins: the css-wide keyword is a no-op<br>
<bramus> emilio: would override decl in the same block<br>
<bramus> TabAtkins: if you do color: revert-rule is same as writing it not at all<br>
<bramus> lea: in prcatice youd not do that<br>
<bramus> … you could var(--sth, revert-rule)<br>
<bramus> TabAtkins: that is fine<br>
<bramus> emilio: that would work<br>
<bramus> TabAtkins: if you use it literally you need the fn<br>
<bramus> emilio: the variable fallback case addresses some of the syntactic boiler plate thing<br>
<bramus> TabAtkins: i see an issue about first-valid to decide on its name<br>
<bramus> TabAtkins: can go for resolution about revert-rule keyword<br>
<bramus> astearns: comments or qs?<br>
<bramus> … objections?<br>
<bramus> RESOLVED: Add revert-rule as a css-wide keyword<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10443#issuecomment-2627865962 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 31 January 2025 17:29:31 UTC