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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

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.

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.

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

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?

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Brian Birtles-2
(2012/12/20 3:29), Tab Atkins Jr. wrote:
> 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.

Sounds good to me. We already added this to Web Animations a few months
back for similar reasons but the diagram and description there are
wrong.[1] It probably should match what you describe here.

Best regards,

Brian

[1] https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html,
section 7.3 Timing in discrete steps

Reply | Threaded
Open this post in threaded view
|

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

L. David Baron
In reply to this post by Tab Atkins Jr.
On Wednesday 2012-12-19 10:29 -0800, Tab Atkins Jr. wrote:
> 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:

I like the idea, but I find the name confusing; it sounded like
something that would give the first and last steps half the duration
of the other steps.  (I also find the description quoted above
confusing, but the rest of the email made it clear.)

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                           http://www.mozilla.org/   𝄂

Reply | Threaded
Open this post in threaded view
|

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

Sylvain Galineau
In reply to this post by Tab Atkins Jr.

[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


Reply | Threaded
Open this post in threaded view
|

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

Sylvain Galineau

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:[hidden email]]
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

smart car lovemysmartcar.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].

 

 

Reply | Threaded
Open this post in threaded view
|

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

Tab Atkins Jr.
In reply to this post by L. David Baron
On Wed, Dec 19, 2012 at 6:40 PM, L. David Baron <[hidden email]> wrote:

> On Wednesday 2012-12-19 10:29 -0800, Tab Atkins Jr. wrote:
>> 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:
>
> I like the idea, but I find the name confusing; it sounded like
> something that would give the first and last steps half the duration
> of the other steps.  (I also find the description quoted above
> confusing, but the rest of the email made it clear.)

I have absolutely no attachment to the name.  It was the first thing
that came to mind.

I assume that Rachel's suggestion comes from her association of
steps(n, end) with meaning "eat the end of the animation" (and
likewise for "start"), so "none" is reasonable in that sense.  I'm not
sure it makes sense if your understanding comes from the spec's
explanation, though, where "end" means "transitions all at once at the
end of the step".

Another possibility is just a new function.  I'm not sure what I'd
want to name it, though.

~TJ

Reply | Threaded
Open this post in threaded view
|

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

Dean Jackson-7
In reply to this post by Tab Atkins Jr.

On 20/12/2012, at 5:29 AM, Tab Atkins Jr. <[hidden email]> wrote:

> 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?

Sounds good to me and worth adding! Having read the other messages in this thread, I have no opinion on naming.

Dean


Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Brian Birtles-2
In reply to this post by Tab Atkins Jr.
On 2012/12/21 3:46, Tab Atkins Jr. wrote:

> On Wed, Dec 19, 2012 at 6:40 PM, L. David Baron <[hidden email]> wrote:
>> On Wednesday 2012-12-19 10:29 -0800, Tab Atkins Jr. wrote:
>>> 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:
>>
>> I like the idea, but I find the name confusing; it sounded like
>> something that would give the first and last steps half the duration
>> of the other steps.  (I also find the description quoted above
>> confusing, but the rest of the email made it clear.)
>
> I have absolutely no attachment to the name.  It was the first thing
> that came to mind.
>
> I assume that Rachel's suggestion comes from her association of
> steps(n, end) with meaning "eat the end of the animation" (and
> likewise for "start"), so "none" is reasonable in that sense.  I'm not
> sure it makes sense if your understanding comes from the spec's
> explanation, though, where "end" means "transitions all at once at the
> end of the step".
>
> Another possibility is just a new function.  I'm not sure what I'd
> want to name it, though.

I spoke with Rachel and a few others about this recently and we were
wondering about the name step-equal? Unfortunately, that doesn't
translate into a function very well ('step-equal(2)'? Alternatively,
what about 'step-stagger' and 'stagger(5)', or just the function?).

I'd like to settle on this soon because Chrome is shipping
Element.animate() with support for 'step-middle' as defined by Web
Animations.[1] We went to implement this in Firefox[2] but I'm concerned
that there aren't use cases for step-middle as currently specced and
instead what we want is what Tab originally proposed in this thread.

Assuming usage is low in Chrome, I'd like to drop step-middle from Web
Animations and replace it with this revised timing function.

Best regards,

Brian

[1] http://w3c.github.io/web-animations/#typedef-step-timing-function
I didn't realize Chrome had implemented this, or else I would have
brought this up sooner.
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1248340

Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Rachel Nabors
I was thinking of "steps(5, equal)" when discussing this syntax, as an expansion of the steps() formula. I think it looks sensible, if that's possible?
On Mon, Mar 7, 2016 at 9:00 PM Brian Birtles <[hidden email]> wrote:
On 2012/12/21 3:46, Tab Atkins Jr. wrote:
> On Wed, Dec 19, 2012 at 6:40 PM, L. David Baron <[hidden email]> wrote:
>> On Wednesday 2012-12-19 10:29 -0800, Tab Atkins Jr. wrote:
>>> 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:
>>
>> I like the idea, but I find the name confusing; it sounded like
>> something that would give the first and last steps half the duration
>> of the other steps.  (I also find the description quoted above
>> confusing, but the rest of the email made it clear.)
>
> I have absolutely no attachment to the name.  It was the first thing
> that came to mind.
>
> I assume that Rachel's suggestion comes from her association of
> steps(n, end) with meaning "eat the end of the animation" (and
> likewise for "start"), so "none" is reasonable in that sense.  I'm not
> sure it makes sense if your understanding comes from the spec's
> explanation, though, where "end" means "transitions all at once at the
> end of the step".
>
> Another possibility is just a new function.  I'm not sure what I'd
> want to name it, though.

I spoke with Rachel and a few others about this recently and we were
wondering about the name step-equal? Unfortunately, that doesn't
translate into a function very well ('step-equal(2)'? Alternatively,
what about 'step-stagger' and 'stagger(5)', or just the function?).

I'd like to settle on this soon because Chrome is shipping
Element.animate() with support for 'step-middle' as defined by Web
Animations.[1] We went to implement this in Firefox[2] but I'm concerned
that there aren't use cases for step-middle as currently specced and
instead what we want is what Tab originally proposed in this thread.

Assuming usage is low in Chrome, I'd like to drop step-middle from Web
Animations and replace it with this revised timing function.

Best regards,

Brian

[1] http://w3c.github.io/web-animations/#typedef-step-timing-function
I didn't realize Chrome had implemented this, or else I would have
brought this up sooner.
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1248340
Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Brian Birtles-2
On 2016/03/09 7:24, Rachel Nabors wrote:
> I was thinking of "steps(5, equal)" when discussing this syntax, as an
> expansion of the steps() formula. I think it looks sensible, if that's
> possible?

Works for me.

"start" and "end" refer to where the step takes place, while "equal"
doesn't but actually influence the length of each segment, so it's a bit
odd. Still, I think it's ok.

If we can't find a suitable keyword to stick into steps(), then another
option is to mint a completely separate function (e.g. stagger(),
quantize() etc.).

> On Mon, Mar 7, 2016 at 9:00 PM Brian Birtles <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On 2012/12/21 3:46, Tab Atkins Jr. wrote:
>      > On Wed, Dec 19, 2012 at 6:40 PM, L. David Baron
>     <[hidden email] <mailto:[hidden email]>> wrote:
>      >> On Wednesday 2012-12-19 10:29 -0800, Tab Atkins Jr. wrote:
>      >>> 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:
>      >>
>      >> I like the idea, but I find the name confusing; it sounded like
>      >> something that would give the first and last steps half the duration
>      >> of the other steps.  (I also find the description quoted above
>      >> confusing, but the rest of the email made it clear.)
>      >
>      > I have absolutely no attachment to the name.  It was the first thing
>      > that came to mind.
>      >
>      > I assume that Rachel's suggestion comes from her association of
>      > steps(n, end) with meaning "eat the end of the animation" (and
>      > likewise for "start"), so "none" is reasonable in that sense.
>     I'm not
>      > sure it makes sense if your understanding comes from the spec's
>      > explanation, though, where "end" means "transitions all at once
>     at the
>      > end of the step".
>      >
>      > Another possibility is just a new function.  I'm not sure what I'd
>      > want to name it, though.
>
>     I spoke with Rachel and a few others about this recently and we were
>     wondering about the name step-equal? Unfortunately, that doesn't
>     translate into a function very well ('step-equal(2)'? Alternatively,
>     what about 'step-stagger' and 'stagger(5)', or just the function?).
>
>     I'd like to settle on this soon because Chrome is shipping
>     Element.animate() with support for 'step-middle' as defined by Web
>     Animations.[1] We went to implement this in Firefox[2] but I'm concerned
>     that there aren't use cases for step-middle as currently specced and
>     instead what we want is what Tab originally proposed in this thread.
>
>     Assuming usage is low in Chrome, I'd like to drop step-middle from Web
>     Animations and replace it with this revised timing function.
>
>     Best regards,
>
>     Brian
>
>     [1] http://w3c.github.io/web-animations/#typedef-step-timing-function
>     I didn't realize Chrome had implemented this, or else I would have
>     brought this up sooner.
>     [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1248340
>


Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Tab Atkins Jr.
In reply to this post by Brian Birtles-2
On Mon, Mar 7, 2016 at 9:00 PM, Brian Birtles <[hidden email]> wrote:

> On 2012/12/21 3:46, Tab Atkins Jr. wrote:
>> On Wed, Dec 19, 2012 at 6:40 PM, L. David Baron <[hidden email]> wrote:
>>>
>>> On Wednesday 2012-12-19 10:29 -0800, Tab Atkins Jr. wrote:
>>>>
>>>> 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:
>>>
>>>
>>> I like the idea, but I find the name confusing; it sounded like
>>> something that would give the first and last steps half the duration
>>> of the other steps.  (I also find the description quoted above
>>> confusing, but the rest of the email made it clear.)
>>
>>
>> I have absolutely no attachment to the name.  It was the first thing
>> that came to mind.
>>
>> I assume that Rachel's suggestion comes from her association of
>> steps(n, end) with meaning "eat the end of the animation" (and
>> likewise for "start"), so "none" is reasonable in that sense.  I'm not
>> sure it makes sense if your understanding comes from the spec's
>> explanation, though, where "end" means "transitions all at once at the
>> end of the step".
>>
>> Another possibility is just a new function.  I'm not sure what I'd
>> want to name it, though.
>
>
> I spoke with Rachel and a few others about this recently and we were
> wondering about the name step-equal? Unfortunately, that doesn't translate
> into a function very well ('step-equal(2)'? Alternatively, what about
> 'step-stagger' and 'stagger(5)', or just the function?).
>
> I'd like to settle on this soon because Chrome is shipping Element.animate()
> with support for 'step-middle' as defined by Web Animations.[1] We went to
> implement this in Firefox[2] but I'm concerned that there aren't use cases
> for step-middle as currently specced and instead what we want is what Tab
> originally proposed in this thread.
>
> Assuming usage is low in Chrome, I'd like to drop step-middle from Web
> Animations and replace it with this revised timing function.

Yeah, WA's "middle" value doesn't do a very useful thing - it does at
least *show* the starting and ending values, but only for a
half-interval each.  I'm not sure where this came from - was it just a
misreading of the original request, maybe?

On Tue, Mar 8, 2016 at 2:24 PM, Rachel Nabors <[hidden email]> wrote:
> I was thinking of "steps(5, equal)" when discussing this syntax, as an
> expansion of the steps() formula. I think it looks sensible, if that's
> possible?

I'm not a huge fan of that name - step() *always* splits it into equal
pieces, so it's not clear why this one in particular is more "equal"
than the others.

I'm feeling like a new function entirely might be a good thing - the
stagger() name works for me. Another possibility is discrete().
(Benefit - the behavior of "non-animatable" values, which we usually
informally call "discrete animation", is precisely discrete(2) or
"discrete" if we added a keyword for the minimal form.)

Mainly I'd like to pretend step() doesn't exist at all - the
step-start and step-end keywords are useful, but going to >1 steps
with those behaviors is just somewhat confusing imo.  Maybe we can add
a note to step() saying that its behavior is confusing, and authors
probably want to use discrete()?

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

L. David Baron
Another possibility, working from the idea that steps(N, start/end)
is pretty broken and this is generally the desired way to do
multiple steps (i.e., not step-start and step-end which are a single
step) is that this function with equal steps could simply be:
  steps(N)
with no second argument at all.

-David

--
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Tab Atkins Jr.
On Tue, Mar 8, 2016 at 3:29 PM, L. David Baron <[hidden email]> wrote:
> Another possibility, working from the idea that steps(N, start/end)
> is pretty broken and this is generally the desired way to do
> multiple steps (i.e., not step-start and step-end which are a single
> step) is that this function with equal steps could simply be:
>   steps(N)
> with no second argument at all.

That has backwards-compatibility concerns - currently, if you omit the
keyword it defaults to "end".

Hmm. If we did do this, it'd mean we'd slightly reinterpret the N
value - rather than indicating the number of segments, it would be the
number of *discrete jumps*.  They'd default to being equally spaced
across the duration, and you can provide a keyword to optionally
indicate that the first/last jump should instead occur at the
start/end of the duration.  (The start/end values aren't *terrible*,
they're just not what people actually want in common cases.)

If we think the back-compat isn't bad, tho, I do like this the best.
We'd then get to add a "step" keyword, too, which is a shorthand for
"steps(1)", and gives the default "non-animatable value" behavior.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Brian Birtles-2
On 2016/03/09 8:59, Tab Atkins Jr. wrote:
> If we think the back-compat isn't bad, tho, I do like this the best.
> We'd then get to add a "step" keyword, too, which is a shorthand for
> "steps(1)", and gives the default "non-animatable value" behavior.

I couldn't work out how to search GitHub for this (since it just ignores
braces) but even just searching our Gecko repository I came up a few
instances of steps(N).[1] One in some codemirror styles and one in
Pocket styles.

I'm not sure where next to look for data, but I suspect that this isn't
going to work out from a compatibility point of view.

discrete() seems good to me unless we can find another way to make
steps() work.

Brian

[1]
https://dxr.mozilla.org/mozilla-central/search?q=regexp%3A%22steps%5C(%5Cd%2B%5C)%22+ext%3Ahtml+ext%3Acss&redirect=false&case=true


Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Rachel Nabors
1) as an animator discrete makes no sense at all to me. I don't even know where I'd begin explaining it to a student or a fellow animation wonk. Vote down.

2) stagger has a meaning closer to "sequence" with people using libraries like GSAP: http://greensock.com/stagger For clarity among the people who will want to use this API the most, I vote this down.

3) I'm in favor of pretending steps don't exist.

4) I encourage this conversation to happen with the animation community at slack.animationatwork.com

5) Otherwise and I light of #3 above, might I suggest chunk(x)? As often this behavior is described as "taking and animation and splitting it into even chunks"

6) oh hey, maybe split(x)...
On Tue, Mar 8, 2016 at 4:46 PM Brian Birtles <[hidden email]> wrote:
On 2016/03/09 8:59, Tab Atkins Jr. wrote:
> If we think the back-compat isn't bad, tho, I do like this the best.
> We'd then get to add a "step" keyword, too, which is a shorthand for
> "steps(1)", and gives the default "non-animatable value" behavior.

I couldn't work out how to search GitHub for this (since it just ignores
braces) but even just searching our Gecko repository I came up a few
instances of steps(N).[1] One in some codemirror styles and one in
Pocket styles.

I'm not sure where next to look for data, but I suspect that this isn't
going to work out from a compatibility point of view.

discrete() seems good to me unless we can find another way to make
steps() work.

Brian

[1]
https://dxr.mozilla.org/mozilla-central/search?q=regexp%3A%22steps%5C(%5Cd%2B%5C)%22+ext%3Ahtml+ext%3Acss&redirect=false&case=true

Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Tab Atkins Jr.
On Wed, Mar 9, 2016 at 12:40 AM, Rachel Nabors <[hidden email]> wrote:
> 1) as an animator discrete makes no sense at all to me. I don't even know
> where I'd begin explaining it to a student or a fellow animation wonk. Vote
> down.

I'm actually super-curious about why this doesn't make sense to you.
How does saying "the animation happens in discrete steps, rather than
a continuous change" feel to you?

> 4) I encourage this conversation to happen with the animation community at
> slack.animationatwork.com

Definitely. I keep forgetting to sign up for that, done now. ^_^

> 5) Otherwise and I light of #3 above, might I suggest chunk(x)? As often
> this behavior is described as "taking and animation and splitting it into
> even chunks"
>
> 6) oh hey, maybe split(x)...

Yeah, these aren't bad imo.  Definitely ones to put on the list.

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Rachel Nabors
I'm on the road right now so replies are slow! The animation slack has a WAAPI and CSS channel this discussion is perfect for.

As for why "discrete" isn't working for me: it's an general adjective that doesn't describe what the action is so much as color it with personality. It had to be tacked onto "steps" to make sense. You could remove the word from the sentence and the behavior is still perfectly described. It could literally be any adjective: polite, judicious, egalitarian. Discrete means subtle or out of the way. Steps are steps. They don't have any of the qualities these adjectives suggest (unless we include "useful" ;), especially if you think about how this would read to someone whose second language is English.

I'm sure we can find a succinct word. What is the opposite of continual? Besides "staggered" ;) I'll start: divided, consecutive.

(Hmm. Split and chunk are still my favorites.)
On Wed, Mar 9, 2016 at 2:43 PM Tab Atkins Jr. <[hidden email]> wrote:
On Wed, Mar 9, 2016 at 12:40 AM, Rachel Nabors <[hidden email]> wrote:
> 1) as an animator discrete makes no sense at all to me. I don't even know
> where I'd begin explaining it to a student or a fellow animation wonk. Vote
> down.

I'm actually super-curious about why this doesn't make sense to you.
How does saying "the animation happens in discrete steps, rather than
a continuous change" feel to you?

> 4) I encourage this conversation to happen with the animation community at
> slack.animationatwork.com

Definitely. I keep forgetting to sign up for that, done now. ^_^

> 5) Otherwise and I light of #3 above, might I suggest chunk(x)? As often
> this behavior is described as "taking and animation and splitting it into
> even chunks"
>
> 6) oh hey, maybe split(x)...

Yeah, these aren't bad imo.  Definitely ones to put on the list.

~TJ
Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Tab Atkins Jr.
On Wed, Mar 9, 2016 at 9:42 PM, Rachel Nabors <[hidden email]> wrote:

> I'm on the road right now so replies are slow! The animation slack has a
> WAAPI and CSS channel this discussion is perfect for.
>
> As for why "discrete" isn't working for me: it's an general adjective that
> doesn't describe what the action is so much as color it with personality. It
> had to be tacked onto "steps" to make sense. You could remove the word from
> the sentence and the behavior is still perfectly described. It could
> literally be any adjective: polite, judicious, egalitarian. Discrete means
> subtle or out of the way. Steps are steps. They don't have any of the
> qualities these adjectives suggest (unless we include "useful" ;),
> especially if you think about how this would read to someone whose second
> language is English.
>
> I'm sure we can find a succinct word. What is the opposite of continual?
> Besides "staggered" ;) I'll start: divided, consecutive.

Oh! You're thinking of "discreet"! That's a very different word from
"discrete", which is the antonym of "continuous". ^_^

That said, the confusion coming from a near-homograph is a good reason
to downvote "discrete".

~TJ

Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Rachel Nabors
Wowwwww.... spellchecker even kept turning discrete into discreet.

On the bright side: I learned a new word :)


photo
Rachel Nabors
Web Animation Engineer
   

Curator of Web Animation Weekly

Speaking & Workshops


On Thu, Mar 10, 2016 at 2:18 PM Tab Atkins Jr. <[hidden email]> wrote:
On Wed, Mar 9, 2016 at 9:42 PM, Rachel Nabors <[hidden email]> wrote:
> I'm on the road right now so replies are slow! The animation slack has a
> WAAPI and CSS channel this discussion is perfect for.
>
> As for why "discrete" isn't working for me: it's an general adjective that
> doesn't describe what the action is so much as color it with personality. It
> had to be tacked onto "steps" to make sense. You could remove the word from
> the sentence and the behavior is still perfectly described. It could
> literally be any adjective: polite, judicious, egalitarian. Discrete means
> subtle or out of the way. Steps are steps. They don't have any of the
> qualities these adjectives suggest (unless we include "useful" ;),
> especially if you think about how this would read to someone whose second
> language is English.
>
> I'm sure we can find a succinct word. What is the opposite of continual?
> Besides "staggered" ;) I'll start: divided, consecutive.

Oh! You're thinking of "discreet"! That's a very different word from
"discrete", which is the antonym of "continuous". ^_^

That said, the confusion coming from a near-homograph is a good reason
to downvote "discrete".

~TJ
Reply | Threaded
Open this post in threaded view
|

Re: [css-animations][web-animations] steps() timing function sometimes unintuitive

Tab Atkins Jr.
nexii, in the WAAPI Slack, suggested frames(). I liked it when I heard it, and after thinking about it overnight, I like it even more.

frames(N) translates directly - it means "split this animation into N frames".  The "frame" terminology is common enough that the metaphor should be readily understood.  The spelling is simple.  It automatically suggests that both the starting and ending values show up (they have to be in one of the "frames", after all).  It's a noun that is easy to talk about non-technically.

(Obviously N must be 2 or greater. frames(1) would be invalid, same as steps(0). We *could* give frames(1) a meaning, but we'd have to decide whether it has step-start or step-end behavior, and that's better done by the step-start/end keywords already.)

So I think I'm throwing all of my votes behind frames() as the name for this, and then we can mostly forget about steps().

~TJ
12