[css-timing] Names for keyword arguments to steps timing function

[ewilligers]

The decision in today's Paris F2F is that the examples
#1301 (comment)
will be
steps(3, ?), start(3, ?)
steps(4, ?), steps(2, ?)
where the keywords are TBD.

start and end will continue to be supported, but there is the option of aliasing them to new keywords.

[tabatkins]

Related to #136, #1371, and #1301.

At the F2F today, we resolved to accept both of the new "step-like" values: showing both the start and end values during the duration (original use-case for frames() in #136), and showing neither start nor end values during the duration (use-case from gradient transitions in #1371). We also resolved that all of these would be done with the steps() function, and that the numeric argument would describe the number of values shown during the duration/iteration. (That is, in Brian's diagram in #1301 (comment), the numeric arguments will be 3, 3, 4, and 2.)

During the meeting we couldn't come up with good keywords for these two new values, tho. This thread is to address that issue.

There are two families of suggestions:

1. If we keep the existing start and end keywords as they are, they are interpreted as "don't show the start value" and "don't show the end value", respectively. The other two values thus need a "dont' show both" and "do show both" naming scheme.

2. Ignore the existing start/end keywords; assume we'll mark them as legacy keywords. Instead come up with a brand new set of four keywords that work well together.

Either way, we have to account for the fact that a lack of a keyword still default to end behavior. This means we can't, for example, use drop-start || drop-end, with the absence meaning the frames() behavior.

[astearns]

In the first family there were two sub-families of suggestions - one where the keywords all work together to describe the generic effect (don't-show-start, don't-show-end, don't-show-both, do-show-both), and one where we tailor the new values to their expected use cases (keep start and end, do-show-both is mainly intended for the frames case, so use 'frames', and don't-show-both is mainly intended for gradients, so use something like 'stripes')

[tabatkins]

You mean "second family", right? The first family is only adding two new keywords, for the two new behaviors, and having them be consistent with the existing start/end.

[tabatkins]

Brian earlier objected that drop-start is a little misleading; steps(10, drop-start) can be read as "create 10 frames, drop the start one" (so you end up with 9 frames). I find that a reasonable objection.

What about skip-start? I feel like that has slightly different implications. steps(10, skip-start) feels a little more likely to be correctly interpreted as "10 frames, skipping the start value".

[larsenwork]

@tabatkins was there ever any more discussion on this? I think skip-start sounds very intuitive especially if combined with skip-both since it would have similar naming logic to animation-fill-mode

Mockup of the naming (modified from @birtles version)

[tabatkins]

steps(4) acting as shown in your diagram is inconsistent with today's behavior, where the default without a keyword is "end" (aka "skip-end"). It sucks, but we need a separate keyword to trigger that case (like "skip-none" or something).

[larsenwork]

Cool, so something like:

[css-meeting-bot]

The Working Group just discussed Remaining css-timing issue + transition spec to CR, and agreed to the following resolutions:

• RESOLVED: Have keywords be jump-start, jump-end, jump-none, jump-both

The full IRC log of that discussion

<dael> Topic: Remaining css-timing issue + transition spec to CR
<dael> github: https://github.com//issues/1680
<dael> TabAtkins: Previous F2F we accepted behavior that if you say 4 frames you get start and and intermediate or just intermediates. We didn't name them. Last comment in the thread we have names.
<dael> Rossen: We didn't?
<dael> TabAtkins: Nope.
<dael> TabAtkins: Diagram in the last comment has my suggestion.
<dael> TabAtkins: skip-start and skip-end as well as skip-both. We're going with skip over drop because birtles argued that it seemed like if you had 10 frames you'd get 9.
<dael> birtles: When you use this for backwards fill you don't drop the initial value for visual effect and you don't skip either.
<dael> TabAtkins: Outside bounds of the transition
<dael> birtles: It's in the animation.
<dael> TabAtkins: I don't think it's possible to address that without a short sentence in the function.
<dael> birtles: It's prefer inside and outside and have frame areas
<dael> TabAtkins: We decided no sep function at the time. Revisit?
<dael> birtles: THining furhter issue is what number rep. Flat bits or veritical bits?
<dael> TabAtkins: Values across transition.
<dael> birtles: Can we have frames represent the bits and steps number inside and outside and number is jumps.
<dael> TabAtkins: If we have frame why more behavior to steps
<dael> birtles: I think it's [missed] to switch between the different modes. You might want to change keyword
<dael> TabAtkins: I'm doubtful. If we keep steps being number of jumps going from start ti inside or outside means the timing of the things change. When the jumps happen change completely. That's why I saidif we do this we can't interp the number as being jumps.
<dael> TabAtkins: That was the jist of my argument the last time we discussed. It was a mathematical way to look but not human centered.
<dael> birtles: I think you're right. Wondering if we can keep steps meaning number of changes and adding frames.
<dael> TabAtkins: WE could in theory. If that does something useful. I was not thinking it was useful enough.
<dael> birtles: Little easier to understand
<dael> TabAtkins: If you switch steps to refer to number of valuees it's the same meaning across. In diagram at the end value is number of thing syou see during the transition.
<dael> Rossen: On of the main objections from Amelia and Rachel N. was when you say steps 3 and get 2 frames.
<dael> birtles: When you go one mode to another having to change the number is confusing. So when you want frames and animation hits last frame and we end it. THe frames approach is step end. If you want a different effect and you have to change the number is confusing.
<dael> TabAtkins: Can you give details on start and end?
<dael> birtles: You've got a countdown 10-0 and you have a image with the numbers and you shift image along. You've got frames for each and steps. 10 skip 9. Then when it hits 0 it triggers something else. So you want steps end.
<dael> TabAtkins: Still counting down from 10 you want 10 steps. Your end value would be 100% where the 0 fram would show up.
<dael> birtles: I think that you have to do is change the number past the steps to get that difference.
<dael> TabAtkins: I'd like to see an example. I don't see changing the number. Still 10 values, but when the transition is done you end up at a 0 one. If you add a 0 there's now 11 frames so you have to change the number.
<dael> Rossen: Can you help us with what we're trying to resolve?
<dael> TabAtkins: Based o nthread status all we needed to resolve is deciding on names.
<dael> Rossen: We resolved to use steps with int = number of visible frames. Only thing to resolve are the names for the 4 keywords.
<dael> TabAtkins: What was the status as of Aug last year, but birtles revisiting the resolution.
<dael> birtles: I'm not sure it was the right decision.
<dael> birtles: If we're jsut deciding names I still have a concern about skip because you see the first frame.
<dael> TabAtkins: Not during the transition. You don't ease the value outside the transition either.
<dael> TabAtkins: I agree drop was misleading. skip is possibly misleading but less so.
<dael> Rossen: Other suggestions?
<dael> smfr: skip:none is the default?
<dael> TabAtkins: skip:end unfortunately.
<dael> TabAtkins: Part of the justification for a separate function was this. We had settled on steps. We can review, but I'm happy sticking.
<dael> birtles: I think it's hte case where you want to keep step height the same?
<dael> TabAtkins: amt of transitions between each frame
<dael> birtles: keep height of steps same....
<dael> TabAtkins: Andres exmple at the bottom, they all have the same height.
<Rossen> jump-start
<dael> birtles: THat was the concern if you want to change between something that triggers the moment it's the last number vs waiting until you get the last number. That seems a little unfortunate.
<dael> TabAtkins: That's because only 9 are in the transition.
<Rossen> steps(3, jump-start)
<dael> birtles: When we had the project it's awk to explain go from 11 to 10.
<dael> smfr: I would expect steps to be number of vertical dotted lines.
<dael> TabAtkins: But that doesn't match a number of authors understanding. WE had that discussion and resolved a different way. We can re-discuss. Original remaining item was to name. We can go as deep as y'all want to do
<dael> birtles: start-skip vs start and end alias
<dael> TabAtkins: I'm doing alias for consistent construction. start and end by themselves are kind of confusing.
<dael> Rossen: Anyone coming around on this?
<dael> TabAtkins: Do people want to re-litigate? If not let's name.
<dael> birtles: Only alternative I'm interested in is aliasing a sep function so number of steps always means number of veritical rises and a sep function for number of values. If you're not interested in that we can resolve.
<dael> Rossen: I'm hearing no one is willing to re-litigate.
<dael> Rossen: Remaining thing is can we live with those names.
<dael> eric: If you're outside the us jump-start makes more sense.
<dael> TabAtkins: I'm okay with jump. There's a jump at the start or the end.
<dael> Rossen: So jump-start has become a thing?
<dael> TabAtkins: Let's do it.
<TabAtkins> jump-start/end/none/both
<dael> Rossen: Proposal: Have keywords be jump-start, jump-end, jump-none, jump-both
<dael> RESOLVED: Have keywords be jump-start, jump-end, jump-none, jump-both