w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.52k stars 672 forks source link

[css-easing-2] Custom curve-based easing functions #7508

Open jakearchibald opened 2 years ago

jakearchibald commented 2 years ago

https://github.com/w3c/csswg-drafts/issues/229 was solved with linear(), which allows easings to be defined by a series of points that are linearly interpolated.

Many easings are curve-based, so there's space for a more efficient syntax that allows curves to be defined.

Some ideas/points from https://github.com/w3c/csswg-drafts/issues/229:

tabatkins commented 2 months ago

To finish out the list of currently-suggested additional easing ideas:

Agenda+ to discuss at TPAC, to see if we want to pursue any of these right now, or defer them.

css-meeting-bot commented 2 months ago

The CSS Working Group just discussed [css-easing-2] Custom curve-based easing functions.

The full IRC log of that discussion <fantasai> TabAtkins: Easying 2 spec added linear() function
<fantasai> TabAtkins: which allows any timing function you want in theory, but annoying if non-trivial function
<fantasai> TabAtkins: so there's a big batch of suggestions for other timing functions
<fantasai> TabAtkins: Possibilities include
<fantasai> piecewise cubic splines
<fantasai> SVG paths
<fantasai> other cubic-splines ideas
<flackr> q+
<fantasai> cubic-bezier
<fantasai> spring
<fantasai> midpoint
<fantasai> stacking easing functions
<fantasai> chaining easing function
<fantasai> easing based on math, e.g. supply a sin() function or whatever
<fantasai> JS-driven easing functions, 2 variants
<fantasai> TabAtkins: I want to decide which ones we want to include in easing 2 vs defer
<fantasai> TabAtkins: inclined to do just chaining and cubic-splining
<fantasai> TabAtkins: but could also be sold on spring
<kbabbitt> q+
<fantasai> TabAtkins: otherwise at some point will ask for a cutoff
<emilio> q+
<fantasai> TabAtkins: opinions?
<astearns> ack flackr
<ydaniv> q+
<fantasai> flackr: Don't have strong opinions on which specific function
<fantasai> flackr: but if using automatic duration for spring(), usually compute based on a distance
<fantasai> flackr: but animations don't currently have a distance
<fantasai> flackr: some hard to know what it would be, others there's no distance (e.g. color)
<fantasai> flackr: so we'll need an answer to that if we want to do it
<astearns> ack kbabbitt
<fantasai> kbabbitt: I only have an opinion on JS-driven. I understand desire, but either need to super constrain or will not be able to run performantly
<fantasai> TabAtkins: if JS available, generating a sufficient precise linear() is trivial, just do it
<astearns> ack emilio
<fantasai> emilio: 1st comment in issue also mentions SVG paths
<fantasai> emilio: how would you do that?
<fantasai> TabAtkins: similar to cubic-bezier()
<fantasai> TabAtkins: restrictions force it to be a function (one y per x)
<fantasai> TabAtkins: idk, don't think we should pursue
<fantasai> emilio: [mumble]
<astearns> ack ydaniv
<fserb> q+
<fantasai> ydaniv: I think we can pursue the math function one
<fantasai> ydaniv: using same syntax we have today for relative color
<fantasai> ydaniv: it will probaby kill the JS-driven use cases
<fantasai> ydaniv: and will cover a lot of easings that can be closely handled by cubic-bezier etc.
<fantasai> ydaniv: so that's worth trying
<fantasai> ydaniv: regarding spring(), might be difficult if we define something that gives you a duration that's not immediately known
<fantasai> ydaniv: stuff in Web Animations 2 like group effect
<fantasai> ydaniv: might need to know animation duration ahead of time
<fantasai> TabAtkins: integration with other types of animations makes me uncertain about an easing that has its own duration baked in
<fantasai> TabAtkins: more things to answer
<astearns> ack fserb
<fantasai> fserb: +1 to avoid the cubic-bezier and to use spline
<fantasai> fserb: because the code to handle that is awful
<fantasai> fserb: I think spline? is generic enough
<fantasai> fserb: if can do chaining etc then should be good enough
<fantasai> fserb: I think math-based is not good. Chaining is easier to understand
<fantasai> fserb: given that ? is not easy
<fantasai> fserb: given what I've seen people try to do
<fantasai> fserb: I have list of advanced cases, e.g. mobiel has special easings etc.
<fantasai> s/mobiel/mobile
<fantasai> TabAtkins: idk if multi-spline is fully general, but it can do a lot of htings including spring
<fantasai> fserb: Way specified, it allows for discontuity
<fantasai> astearns: enough feedback, Tab?
<TabAtkins> TabAtkins: yep
tabatkins commented 2 months ago

Quick summary of the discussion in the room (not final by any means)