- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 28 Jan 2026 18:50:26 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-easing] Allow `steps()` to accept an easing function as the `<step-position>` ``, and agreed to the following: * `RESOLVED: Allow simple easing functions as params to steps() as described in the issue` * `ACTION: Make sure there's an open issue on composing easing functions` <details><summary>The full IRC log of that discussion</summary> <bramus> Demo: https://vasilis.nl/clocks/station-clock/01/<br> <fantasai> bramus: recreates a clock, wants to have some easing in between seconds<br> <fantasai> bramus: but steps() defines a number of steps and then creates a staircase<br> <TabAtkins> q+<br> <fantasai> bramus: suggestion to add extra argument that allows to specify easing<br> <bramus> https://github.com/w3c/csswg-drafts/issues/11970#issuecomment-2747746414<br> <flackr> q+<br> <fantasai> bramus: This demo I shared in IRC, very useful to have `steps(ease, 60)` which would give the chart here<br> <fantasai> bramus: Otherwise author has to pre-generate keyframes with 60 entries etc.<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: fantasai and I reviewed before F2F and think it's a fine idea<br> <fantasai> TabAtkins: Just need to make sure exactly where the intermediate values are. Diagram matches what we expect - match jump-start/jump-end rather than jump-none/jump-both<br> <kizu> +1 too<br> <fantasai> TabAtkins: Would just add this instead of existing keywords<br> <astearns> ack flackr<br> <fantasai> flackr: One of the easing possibilities is steps() ...<br> <fantasai> TabAtkins: Oh. Yeah everything except those. :)<br> <fantasai> flackr: Broadly that seems reasonable.<br> <fantasai> flackr: For the original use case, compsiting animations would work<br> <fantasai> flackr: We also have iteration-delay to delay repeated animations<br> <fantasai> flackr: Not opposed to having both, but there is a path to solving the problem<br> <fantasai> flackr: which gives you different controls over the space, potentially<br> <fantasai> flackr: For example, what if you wanted an ease animation starting from halfway through a step?<br> <ChrisLilley> q+ to complain a bit<br> <fantasai> flackr: iteration-delay 500ms + ease would have that solution<br> <fantasai> bramus: Would that block this addition?<br> <fantasai> flackr: Going back to original use case, usually the tick itself is much less than 1s long.<br> <fantasai> flackr: You want 100ms animation at each second<br> <fantasai> flackr: So I'm worried that the solution proposed here makes that case difficult<br> <fantasai> flackr: because you want linear with delayed effect<br> <fantasai> TabAtkins: If you wanted to do iterations, how would you set it up?<br> <fantasai> flackr: You could have a single animation of a single second rotation<br> <fantasai> flackr: 1s arc rotation<br> <fantasai> flackr: and you'd have 60 iterations so that it proceeds around the whole clock<br> <fantasai> flackr: and then iteration-delay would be 1s - animation-duration<br> <fantasai> TabAtkins: so it would be an additive animation<br> <fantasai> bramus: we don't have that?<br> <fantasai> flackr: It's implemented in Blink<br> <astearns> ack ChrisLilley<br> <Zakim> ChrisLilley, you wanted to complain a bit<br> <fantasai> ChrisLilley: When SMIL added animation and SVG added it, we had a professional animator say it's a rubbish spec<br> <fantasai> ChrisLilley: because it's piecewise linear, which allows simulating a smooth curve<br> <fantasai> ChrisLilley: if points are changing, you have to do that calculation itself<br> <fantasai> ChrisLilley: we have easing but still have to precalculate it and don't have a "real animation system"<br> <fantasai> ChrisLilley: We have an "almost good enough it'll do for now" system<br> <fantasai> ChrisLilley: But every time we add bits, I die a little more inside.<br> <kizu> q+<br> <fantasai> flackr: I think you're arguing in favor of not doing this in steps() and doing iteration compositoin?<br> <bramus> q+<br> <fantasai> ChrisLilley: [yes?]<br> <bramus> scribe+<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to ask about composing easing functions<br> <bramus> fantasai: do we have or want the ability to compose easing functions by addng them toeghter?<br> <bramus> … then we could add a ??? with a delay<br> <bramus> flackr: has come up 1 or 2 times before<br> <fantasai> fantasai: could add linear + ease + something else or whatever<br> <fantasai> flackr: we do have animation-wide easing separate from inter-key easing<br> <ChrisLilley> s/[yes?]/yes<br> <fantasai> flackr: but more generally composing is sometimes useful<br> <fantasai> flackr: most common case is making frame-limited animations, where you want a smooth easing functions but only at e.g. 30fps<br> <fantasai> flackr: So... maybe?<br> <fantasai> flackr: idk how often it's useful<br> <astearns> ack kizu<br> <fantasai> kizu: +1 to being able to achieve this, ideally easier<br> <fantasai> kizu: If you can work around this with composite animations, that means you need to know how<br> <fantasai> kizu: it will not be one animation, you'll have to do multiple things<br> <fantasai> kizu: it will only work for things that are composable, right?<br> <fantasai> kizu: so you can't animate things that are not composable this way<br> <fantasai> kizu: I remember I've wanted to do things like this, multiple steps with easing between them<br> <fantasai> kizu: Unless this really introduces some issues, or we have other things we want to do<br> <fantasai> kizu: this looks like a very simple thing to use from author perspective<br> <fantasai> kizu: you can use linear() or bezier() inside<br> <fantasai> kizu: and it'll just work<br> <fantasai> kizu: so I think very often in CSS, yeah maybe we should have one wya to do this, but actually different use cases prefer differnet methods<br> <fantasai> kizu: so I think it's useful to have both compositing and this<br> <fantasai> flackr: I think what fantasai was getting at was more generally being able to combine easing functions<br> <fantasai> flackr: I do want to push back that even with iteration composite, it's one iterating animation<br> <astearns> ack bramus<br> <fantasai> flackr: you define the clock and then repeat the animation by 60s<br> <fantasai> bramus: Can ony do iteration compositionin Web Animations, right? Not in CSS?<br> <fantasai> flackr: not sure, no reason it can't be available in CSS<br> <bramus> https://github.com/w3c/csswg-drafts/issues/1332#issuecomment-3649356666<br> <fantasai> bramus: Use cases, other issue where it was mentioned is this one<br> <fantasai> bramus: using steps() function inside a linear gradient<br> <fantasai> bramus: so animation approach wouldn't work<br> <fantasai> astearns: Wonder if we could take out this specific case and work out with composite animations?<br> <fantasai> astearns: so we could look at the difference between the 2 approaches and whether we want both or one<br> <fantasai> fantasai: well it wouldn't solve gradients<br> <fantasai> flackr: making more general than steps<br> <bramus> fantasai: I think there is some generalizatoins we could to<br> <bramus> … like being able to string a bunch of easing fns together. some linear, some bezier … not have to try and put it in one function<br> <bramus> … some bits linear, some bits not<br> <bramus> … that is a separate feature from here, which is nesting stuff: inside each step do something<br> <bramus> … we would still need to special case this<br> <bramus> … if we were doing generatel composabilty, it would be the steps fn, so we would need this nesting structure anyways<br> <bramus> … idea of taking sth functionally with a set of arguments … now we are expanding that subset of easing fns and turning it into a broader collection of easing fns<br> <bramus> … natural extension<br> <bramus> … instead of just step, you can also ease<br> <bramus> … expanding things<br> <flackr> q+<br> <bramus> … doing some kind of composabilty woudl allow more complicated stuff, but doesn tmeasn we should not do this extension<br> <bramus> … so suggesting to accept this proposal and maybe limit so that you cant recurse … only accept simple easing<br> <astearns> ack flackr<br> <fantasai> flackr: Agree we should do this<br> <fantasai> flackr: Is there a simple way to solve the "only want to use part of the step"<br> <fantasai> flackr: like, wait and then destination?<br> <fantasai> TabAtkins: I think answer to that is more general easing combination<br> <fantasai> TabAtkins: Composite easing with this bit of linear, this bit of ease, and this bit of linear<br> <fantasai> fantasai: Yeah, exactly<br> <fantasai> flackr: Ok, then this extends naturally to that in the future<br> <fantasai> ChrisLilley: Do these need to be absolute or can we do fr units kind of things?<br> <fantasai> fantasai: Don't easing functions do by default?<br> <fantasai> TabAtkins: Yeah, they expand to fill space<br> <fantasai> ChrisLilley: Don't want to paint ourselves into a corner<br> <fantasai> fantasai: don't think this does<br> <fantasai> astearns: So let's allow non-steps easing functions as a steps param?<br> <fantasai> ChrisLilley: single or list?<br> <fantasai> fantasai: Single. Composability is a separate quesiton, but once we sole it it can be put into here<br> <fantasai> RESOLVED: Allow simple easing functions as params to steps() as described in the issue<br> <fantasai> ACTION: Make sure there's an open issue on composing easing functions<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11970#issuecomment-3813211484 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 January 2026 18:50:26 UTC