W3C home > Mailing lists > Public > www-style@w3.org > December 2012

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

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Thu, 20 Dec 2012 05:53:26 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, www-style list <www-style@w3.org>
CC: Rachel Nabors <rachelnabors@gmail.com>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178291BEF871B@TK5EX14MBXC222.redmond.corp.microsoft.com>

[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



Received on Thursday, 20 December 2012 05:54:06 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:03 GMT