[css-timing] reconsider name of frames() timing function

[dbaron]

From https://github.com/w3ctag/design-reviews/issues/161#issuecomment-297617664, it would be good to reconsider the name of the frames() timing function.

[LeaVerou]

Ok, since we're bikeshedding names now, what about discrete()?

[SebastianZ]

That sounds like renaming it to values() would help.

I can get behind that! And it works well for gradients as well, avoiding @LeaVerou's concern.

While I proposed it, I agree with the others that it's a pretty vague name. I'm still for extending the steps() function somehow. parts(), partitions(), fragments(), and segments() are similarly good, but none of them fits perfectly to all examples outlined by Brian.

Sebastian

[fuchsia]

This is almost certainly a dumb question, but why are all these special cases needed? Why can't the correct behaviour be deduced in the animation logic?

For example:

• if the final and initial states of the animation would look the same to the user;
• if the animation is going to repeat;
• if the user asks for frames(N);
• then divide into N+1 frames and display the first N for that run of the loop.

Do something similar looking at the final state (accounting for fill) on the the last run.

And automatically drop the first frame, on the first run, if it it resembles the state before the animation started.

Make frames() do the right thing out the box. If necessary, steps() can be extended for those rare cases when the right thing is wrong.

[tabatkins]

@fuchsia Automatically changing the behavior of a timing function based on the values of other properties is unlikely to be less confusing - it means you can't predict from looking at it how long each frame is! In particular, your suggested code would make the first/last iteration either have frames of different length than the rest of the animation, or have an iteration of different length from the rest of the animation. Both of these have a high chance of being bad due to things becoming unmatched.

[birtles]

Both Firefox and Chrome have decided to delay shipping frames() for the time being to allow this discussion to play out without being constrained by shipping implementations.

[fuchsia]

@tabatkins I think I thought user were being forced to make those decisions explicitly, with the bonus cognitive load of having to grok the issues in the first place. But I probably haven't understood it properly myself, so I'll stop digging (unless you want to use me to rubber duck debug the API.)

[css-meeting-bot]

The CSS Working Group just discussed Name for frames() function., and agreed to the following resolutions:

• RESOLVED: Renames frames to steps, argument name TBD.

The full IRC log of that discussion

<iank_> Topic: Name for frames() function.
<iank_> Github: https://github.com/w3c/csswg-drafts/issues/1301
<glazou> https://github.com/w3c/csswg-drafts/issues/1301
<iank_> birtles: So we specified a frames() timing function, makes sense for a usecase, animation that has discrete frames, and the start and end of the animation doesn't match, and the animatin repeats.
<iank_> birtles: And for that use-case, frames() is a very good way of describing the timing, very obvious name, the counting , the number that you put in that function is the number of frames, unlike steps() where you count the number of jumps.
<iank_> birtles: My concerns with frames, is
<iank_> birtles: 1) very good in that context, not suitable in other contexts, e.g. not a good name for gradients.
<iank_> birtles: 2) Having a different function name for something very similar can be confusing, e.g. frames() to a css transition, has almost idential result to steps() timing function
<iank_> birtles: likewise there has been a proposal for a 4th type of timing function where ... jumps happen at both ends of the interval.
<iank_> birtles: if we introduce that (seems likely) we'd do it as an extension to steps.
<fantasai> Illustration of the 4 options: https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203
<iank_> birtles: means we'd have 4 timing functions, 3 named steps, one frames(), seems inconsistent
<iank_> birtles: Also frames() has bad discoverability, within devtools, (autocomplete)
<iank_> birtles: if you have a steps timing function, and doesn't quite look right, you'd just try and change that TF, not easy to "find" the frames TF instead.
<iank_> birtles: concered that they wouldn't discover frames, and then would have to use a different way of counting.
<glazou> s/concered/concerned
<iank_> birtles: My prefered way of doing this would be to extend steps.
<iank_> birtles: Even though we know that way of counting isn't ideal
<fantasai> birtles: for the particular use case of a repeating frame-based animation that doesn't go back to where it starts
<iank_> Rossen: So looking at the community twitter, that rachael did, frames() was solidly a preference from designers.
<iank_> fantasai: They are only concerned with what they do, not trying to make consistent with the rest of CSS
<iank_> fantasai: I agree with birtles points, agree that its easier to learn the set if its an extension to steps() instead of a new function, (frames())
<iank_> birtles: If you are animating a spinner, and its rotating, you'd want a steps TF, if you use frames() it'll double the length of the other points.
<fantasai> Was pointing out that polling people for their preferred syntax for that particular use case isn't going to take into consideration the interaction with the rest of the system, which is our job here in the WG.
<fantasai> For people who want a function to do the one thing that they're trying to do, yeah, frames() might be nicer. But in general people have to learn more than just the one case
<fantasai> and then for almost the same but not quite cases, they have to switch to steps()
<fantasai> which doesn't seem very helpful
<iank_> Rossen: So the current name in the spec is steps()?
<iank_> birtles: No frames()
<iank_> Rossen: Any other opinions? otherwise can resolve and move on....
<iank_> Rossen: No?
<iank_> Rossen: Any objections to renaming frames() to steps()?
<iank_> birtles: We'd still need to work out the name of the argument.
<iank_> birtles: Some of the proposals have been distribute.
<iank_> astearns: We could resolve on using steps, instead of frames, and work out param names later.
<iank_> fantasai: <showing examples on github issue>
<astearns> s/later/separately/
<iank_> fantasai: <https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203>
<iank_> Rossen: Are there any objections to renaming frames() to steps()?
<iank_> fantasai: In favour.
<astearns> +1
<iank_> RESOLVED: Renames frames to steps, argument name TBD.
<fantasai> fantasai^: These are the four options under consideration for this set of timing functions. The first two exist already, the second two are proposed.
<iank_> fantasai: The next thing is that we have the 'start', 'end'... we need two more keywords.
<iank_> fantasai: We need to be clear of the distiction between the two new keywords.
<astearns> inside/outside, inclusive/exclusive also mentioned
<iank_> fantasai: Proposal to use the space keywords, which we use for distributing space, e.g. 'space-between', 'space-evenly'
<iank_> fantasai: Could also use 'space-around'
<iank_> fremy: space-around only has half of the space....
<iank_> fantasai: we could space-* keywords, could use another word other than space?
<iank_> birtles: could drop the space- prefix, e.g. between, evenly, etc.
<iank_> dino: I'd prefer that anyway, we are going to have to look this up anyway
<iank_> fantasai: At least you've learn't alignment, then we can transfer the knowledge to different area.
<tantek> I've read the entire github issue and I'm still not sure about which of the options are better.
<iank_> astearns: There is the option using the start, end syntax, to start, end, both, none.
<iank_> dbaron: start, end made the most sense for 1 step.
<iank_> <general talking about arg names>
<Bert> ('center' seems nice and short, transition in the middle rather than at the start or end...)
<iank_> Rossen: We can always continue this in the discussion.
<iank_> Rossen: We are already going against tabs strong pushback, it also doesn't sound like we have clear winners on arg names.
<iank_> birtles: Could we at least list the current candidates?
<iank_> birtles: 1) distribute and justify naming.
<iank_> Florian: 2) distribute and stretch
<iank_> birtles: 3) space-evenly, space-between
<iank_> dbaron: 4) center, stretch
<Rossen> steps( <integer>, [ trim-start | trim-end | trim-both | no-trim ]
<iank_> birtles: 5) both, neither
<iank_> Rossen: 5) trim-start, trim-end, trim-both, no-trim
<fantasai> fantasai: Problem with distribute and justify is that they are two words that mean almost the same, and aren't used to make a distinction anywhere else in CSS.
<iank_> Rossen: 6) trim-start, trim-end, trim-both, no-trim*
<fantasai> fantasai: (We also have text-justify: distribute as a legacy thing, which is really not helping here)
<iank_> birtles: Don't like the trim names b/c when you use them you typically don't drop the endpoints, you see the endpoints.
<iank_> Bert: 7) short, long.
<iank_> astearns: 8) include, exclude
<fantasai> fantasai: Problem with using center is that both space-around and space-evenly are centering methods, but they are different. It's not clear which one this is.
<fantasai> I really don't like 1/2/4/7.
<iank_> Rossen: If folks are passionate about this, they can take this offline, and come back to the group, I really want to include TabAtkins , unfortunate to re-resolve this later
<fremy> My pref would be 3 or 4
<iank_> Rossen: Lets close this, if we have a clear set of keywords by the end of the F2F, we can resolve on a later day.

[birtles]

Talking with @fantasai during the break, I like center , stretch (spread?). @fantasai likes space-evenly, space-between and is concerned that if we were to go with center, stretch and later decided we wanted a version that behaves like space-around we will wish we used the space-* naming to begin with.

[css-meeting-bot]

The CSS Working Group just discussed step function parameter names, and agreed to the following resolutions:

• RESOLVED: Use steps() function with the <integer> being number of visible frames during the animation duration

The full IRC log of that discussion

<tantek> topic: step function parameter names
<tantek> TabAtkins: strong objection to anything that resembles sizing or alignment keywords
<tantek> TabAtkins: they are extremely confusing
<tantek> TabAtkins: we have start and end already
<tantek> TabAtkins: imply dropping start or end step
<tantek> TabAtkins: we should come up with two keywords that fit that model
<tantek> astearns: one of the reasons I proposed both and neither
<tantek> Florian: it depends what what the step is, flat or verticle
<tantek> TabAtkins: flat
<tantek> fantasai: vertical
<tantek> s/verticle/vertical
<tantek> TabAtkins: I think for most authors the intuitive model is number of values received
<fantasai> ScribeNick: fantasai
<fantasai> birtles: If you have say, steps(2, start)
<fantasai> birtles: this is what you see as the timing function
<fantasai> birtles: If you're repeating this, you just see those two values, but if you apply this to a transition, you will see the pictures before and after the timing function
<fantasai> TabAtkins: The starting frame there isn't included in the value
<fantasai> birtles: But as an author you're seeing all three values
<fantasai> TabAtkins: if ou say I want transition to last 1s, and steps(2) and the time of the steps don't last .5s each, then it's bad
<fantasai> birtles: I disagree
<fantasai> birtles: We've already resolved we're sticking with steps() and the number is the number of jumps
<fantasai> https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203
<fantasai> TabAtkins: The argument from RachelNabors is that you can't accurately time a tansition or animation that during the preiod shows both the start and end value
<fantasai> TabAtkins: because right now you have to, during the transition, either the starting value is not shown and you jump immediately or
<fantasai> TabAtkins: During a single transition, if you want to see both start and end there, which is a use case RachelNabors brought up, you have to do some non-intuitive duration-manipulation to make it show correctly
<fantasai> TabAtkins: If you want a 3-step frame-based cartoon that lasts 3s then...
<fantasai> birtles: We're talking cross-purposes
<fantasai> birtles: We're all agreeing that this timing function exists
<fantasai> birtles: we're just talking about the syntax for it
<fantasai> birtles: We went over the number of steps this morning
<fantasai> birtles: and resolved on that aspect
<fantasai> dino: I think we agree that there are three steps there, if we're going up a staircase, there are three steps there.
<fantasai> fantasai: We're off-topic, the topic is the name of the keywords not the syntax of the function overall. That was resolved already.
<fantasai> TabAtkins: I object to that
<fantasai> fantasai: oesn't matter, you're off-topic
<fantasai> TabAtkins: There are 4 things being shown !
<fantasai> dino: 4 things shown is 3 steps
<fantasai> TabAtkins: You're thinking about the wrong things.
<fantasai> [rehash of arguments]
<fantasai> TabAtkins: I'm representing RachelNabors, nobody else is!
<fantasai> birtles: I presented the arguments on both sides, and explained why I think that the steps() syntax is the right way to go
<fantasai> birtles: Didn't go with frames() for two reasons
<fantasai> birtles: First is, it's less appropriate for contexts outside of looping animations
<fantasai> birtles: transitions and gradients being examples
<fantasai> birtles [gives more specific examples]
<fantasai> birtles: The other concern was discoverability
<fantasai> birtles: If you start with steps() and it's not quite right, then can't discover frames() behavior by adjusting arguments, and also need to change how you count
<fantasai> birtles: or vice versa
<fantasai> fremy: Your problem is that you count 3 here, what if instead we count 4, but keep it in the steps() function
<fantasai> TabAtkins: If the third one was steps(4, something) and the fourth one was steps(2, somethingelse) then it's fine.
<fantasai> fremy: So you don't object to using steps(), just object to using 3.
<dbaron> dino: So you're counting the number of places you put your foot rather than the number of times you go up.
<fantasai> TabAtkins: Want it to be number of things you see
<fantasai> gregwhitworth: Rachel does say that she's fine to re-use steps().
<ericwilligers> +q
<fantasai> birtles: The tricky bit is that in the first two cases, which we have right now, it just so happens that the number of values you see also matches the number of jumps
<fantasai> birtles: That's why that happens to be okay
<fantasai> birtles: But that's only true when your'e repeating
<fantasai> birtles: If you're transitioning or using animation-fill-mode, then you see more
<fantasai> TabAtkins: But that's not part of the duration
<fantasai> dino: Tab only cases where yo put your foot between the start and the end, doesn't care about what's before or after the start/end
<fantasai> ericwilligers: If we go with wher eyou put your foot, then the bottom left would be steps(4, neither) and the bottom right would be steps(2, both)
<dbaron> referring to the diagram in https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310571203
<fantasai> TabAtkins: Your'e showing neither start nor end during the duration
<gregwhitworth> ^ for reference - here is the comment where RachelNabors
<fantasai> TabAtkins: I think it would be better to have drop-* keywords or something
<gregwhitworth> ^ says that: https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-299749586
<fantasai> TabAtkins: but then you'd have to ...
<fantasai> [mumbling in the corner]
<fantasai> dbaron: I think start and end makde a lot of sense for step-start and step-end
<fantasai> [but maybe less so here]
<TabAtkins> TabAtkins: I agree. They are the correct start/end pairs for single steps.
<fantasai> astearns: So I've heard people say they don't like the idea of having the bottom left be steps(4) and the bototm right be steps(2), but does anyone object to the idea of counting places to put your foot?
<fantasai> TabAtkins: The other people talking about other interpolation stuffs also want 4 and 2
<fantasai> TabAtkins: So I think they're intuitive on their own
<fantasai> birtles: This is a frame based animation here
<fantasai> birtles projects a demo
<fantasai> birtles writes
<fantasai> animation: slide 3s infinite steps(10, start)
<fantasai> birtles: You see you miss frame 1
<birtles> http://slides.com/birtles/browser-animation-2017/live#/3/2
<fantasai> birtles: If I s/start/end, I start at 1, but don't se 10
<fantasai> birtles: If I say frames(11), then I get all the 10 frames
<fantasai> birtles: But to get this effect, I have to change the number
<fantasai> ...
<fantasai> birtles: If you're switching between the two, then you have to change the number
<fantasai> dbaron: Seems like we have one solution that isn't drawing strong objections from people
<fantasai> dbaron: which is to use the steps() function with two new keywords, and count the number of places you put your foot
<fantasai> Bert: Referring back, if you count the number of intermediate steps, there's only 9 intermediate steps
<fantasai> Bert: Some variations, you only see those 9 steps, the first and last are outside the animation itself
<fantasai> [everybody picks a number to shout]
<fantasai> TabAtkins: Using values 10 11 or 9 with some yet-undecided set of keywords, using steps() function name, seems to be drawing least objections.
<fantasai> TabAtkins: Anyone object to that, assuming good keyword names
<fantasai> dbaron: We need to find names that work with the numbers
<fantasai> astearns: Any objections to this proposal?
<dbaron> github: https://github.com/w3c/csswg-drafts/issues/1301
<fantasai> astearns: So we'll add to this morning's resolution that we'll use steps() function with numbers that count the place where you put your foot
<fantasai> astearns: I'm concerned that this will prove confusing
<fantasai> Bert: If you allow 11 here, then 1 makes no sense
<fantasai> Bert: then why not lower the number, and say it's the number of intermediate values
<fantasai> ...
<fantasai> dbaron: Bert is concerned about the allowed range of integers, which will vary depending on the keyword
<dbaron> 1- for the existing keywords, and 0- and 2- for the new keywords
<fantasai> RESOLVED: Use steps() function with the <integer> being number of visible frames during the animation duration
<fantasai> astearns: What should the keywords be
<fantasai> fantasai: If we were starting from scratch I have an ida
<dbaron> fantasai: ... we'd use the same kind of: fill, start-fill, end-fill, and ... we have this concept of fill.
<TabAtkins> dbaron, actually I think the "intermediates only" is also 1+, not 0+. You need to have at least one "intermediate" value to show!
<TabAtkins> dbaron, so the frames() use-case is 2+, the rest are 1+.
<fantasai> fill-start, fill-end, fill-between, fill-evenly
<fantasai> just like alignment
<dbaron> TabAtkins, actually, maybe the new ones are both 2+
<fantasai> fill is time that's filled by a frame
<TabAtkins> dbaron: Nah, "intermediate only" is fine to be 1 - it shows only the 50% value during the animation.
<fantasai> TabAtkins: I'd be ok with 4 new keywords to make a set
<fantasai> s/dbaron:/dbaron,/
<fantasai> TabAtkins: rather than adding to start+end
<fantasai> astearns: What if keywords were talking about where to jump
<dbaron> astearns: You could have the keywords say where you jump. So you have steps(3, start), steps(3, end), steps(4, neither), or steps(2, both).
<fantasai> fremy: 4th one is intermediate only, only shows intermediate only
<fantasai> fremy: 3rd one includes ...
<fantasai> fremy: open set and closed set
<fantasai> fremy: intermediate and
<fantasai> TabAtkins: intermediate is over the desired spelling level
<fantasai> dino: Anyone wants 4th one?
<fantasai> TabAtkins: Yes, definitely have requests for that
<dbaron> Florian: _|¯
<fantasai> TabAtkins: esp for gradients
<Florian> steps(4, _-¯) steps(2, -)
<TabAtkins> linear-gradient(red 20%, steps(5, middle-only), blue 80%) <= 5 color stripes between the red and the blue
<fantasai> fantasai: So both and neither was ...? No, it's really confusing.
<fantasai> TabAtkins: As dbaron was saying, the start/end keywords make sense for the step-* keywords but not so much for the steps() function
<dbaron> Just as long as we don't use steps() and stairs() with two different meanings...
<SimonSapin> steps("▁▃▅▆▇███")
<fantasai> Florian: We do both and neither
<dbaron> Tab: show-end, show-start, show-both, show-neither
<fantasai> fremy: So both is show both start and end, and neither is ..
<fantasai> TabAtkins: No, that's backwards
<fantasai> TabAtkins: because of the way start and end are defined
<fantasai> fremy: screw it, we should do it this way around anyway
<fantasai> TabAtkins: that's okay if we have a prefix, like show-start or
<dbaron> (insert my previous line here)
<fantasai> astearns: So show-end is the same as start
<birtles> steps(4, frames)? (Not sure about the fourth option)
<fantasai> TabAtkins: if we do show keywords we do it this way, if we do drop kewyrods we can match start/end
<fantasai> TabAtkins: But it also was pointed out that drop has some weird impliciations of dropping a frame
<fantasai> TabAtkins: show-* doesn't have that problem or one of adding a frame
<fantasai> dbaron: stripes? :)
<dbaron> (somebody said before me that frames was for animations and the other one was for gradients)
<fantasai> birtles: steps(4, frames) steps(2, stripes)
<fantasai> dbaron: though they all give stripes, just a different set of stripes
<fantasai> fantasai: Oh, I like that Bert. That's better than using start/end with opposite meanings
<melanierichards> +1 to Bert's idea
<Bert> (Putting it on the record: just thinking aloud, but how about: step(n [, show-first || show-last]?) )
<fantasai> although I'd still have both keyword, because it's easier to type
<dbaron> actually 0 does work as the number for the fourth option
<fantasai> and also, how do you get the 4th variant?
<fantasai> Rossen and Tab discuss some examples
<fantasai> TabAtkins: Let's go back to thread with what we've concluded and ask for help
<fantasai> astearns: maybe we should open a new issue
<fantasai> astearns: OK, let's close this issue and open a new one on the new keywords
<TabAtkins> Bert, can't do that one unfortunately, because the "no keyword" case (steps(3)) already means steps(3, start). :(
<TabAtkins> s/steps(3, start)/steps(3, end)/
<fantasai> https://github.com/w3c/csswg-drafts/issues/1609
<fantasai> we could do 1609 but ppl might be fried
<fantasai> sorry https://github.com/w3c/csswg-drafts/issues/951
<fantasai> https://github.com/w3c/csswg-drafts/issues/951#issuecomment-316535854

[ewilligers]

New issue for the keywords: https://github.com/w3c/csswg-drafts/issues/1680