RE: [css3-animations] steps() timing function sometimes unintuitive

start/end refer to which end of the interval updates the value. Given that, ‘none’ suggests it doesn’t update?

Warning: technically we have a few more attempts left before the WG calls it ‘bike-shed’.,,,

From: Rachel Nabors [mailto:rachelnabors@gmail.com]
Sent: Thursday, December 20, 2012 9:17 AM
To: Sylvain Galineau
Cc: Tab Atkins Jr.; www-style list
Subject: Re: [css3-animations] steps() timing function sometimes unintuitive

I love the direction this discussion is going in!

But I must say that I too find steps(x, step-mid) confusing as far as name indicating behavior. What about all or equal or even none?

Just throwing some ideas out there. Right now, steps(x, none) feels the most "right" to me in light of existing naming conventions and behavior.

Rachel Nabors
***
Web Ramblings RachelNabors.com<http://RachelNabors.com>
smart car lovemysmartcar.com<http://lovemysmartcar.com>
Comics RacheltheGreat.com<http://RacheltheGreat.com>

On Thursday, December 20, 2012 at 12:53 AM, Sylvain Galineau wrote:

[Tab Atkins Jr.:]

I recently attended a great talk by Rachel Nabors about using CSS
Animations to do "music videos", and while there heard an interesting
complaint about the steps() function that I think we should address in the
next level.

The issue is that steps() looks like it "eats" either the start or end
keyframe. For example, say you have a background-position-x animation
going from 0px to 60px, with a timing function of steps(3) over 6 seconds.
The behavior is:

0s 0px
| 0px
| 0px
v 0px
2s 20px
| 20px
| 20px
v 20px
4s 40px
| 40px
| 40px
| 40px
v 40px
6s 60px

The animation officially hits 60px, but only at the literal last instant,
and if you're not filling forward, you'll never see it. So, it *looks*
like the background was just animated from 0px to 40px.
You get a similar problem with the starting value disappearing if you use
step-start. The only way to work around this is to "overshoot"
your target - instead of doing the above, make it a 4-step animation from
0px to 80px, so that it spends 1.5s each with 0px, 20px, 40px, and 60px.

I'll admit this still confuses me when I use steps().


Our current behavior makes sense, of course - it's a simple consequence of
splitting the animation curve into 3 segments and making each of those
segments a step - but it's unintuitive for someone who just wants to see
the animation start at one value, end at another, and make a few discrete
steps in between.

Exactly; the function's name maps 'number of steps' to 'number of intervals'
and that's why it's confusing.

I propose another steps value: step-mid. It splits the animation curve
into n segments, makes the first n-1 do step-end behavior, and leaves the
last to just run normally. The above example could instead be written as
"steps(4, step-mid)" and have this behavior:

0s 0px
| 0px
| 0px
v 0px
1.5s 20px
| 20px
| 20px
v 20px
3s 40px
| 40px
| 40px
| 40px
v 40px
4.5s 60px
| 60px
| 60px
| 60px
v 60px
6s 60px

Yeah, that works Like David I'm less sure about the name. If the semantics of
steps() are confusing step-mid may be more so relative to start/end. It suggests
updating in the middle of each intervals (to me, anyway). Also, going from 2s
intervals to 1.5s interval does not feel like a 'mid' effect.

Finding a way to convey 'steps(n,end) except for the last frame' is not easy.
end-unless-last seems wordy. end-inside feels too vague. end-distribute to suggest
each end should be visible for the same amount of time?

Like I said, I don't think this is a major issue to address at this level,
but would like it considered for Animations 4. Thoughts?
Filed as bug 20454 [1].

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=20454