Re: [csswg-drafts] [css-timing] reconsider name of frames() timing function

I'm theoretically okay with changing the name away from `frames()`, to make something that works better with #1371, but I'm still strongly against reusing `steps()`. The behavior is substantially different, and if you try align your mental model of the behaviors, then the interpretation of the numbers and keywords vary in confusing ways.  (The aforementioned confusion with "start" not meaning "include the start value".)

I feel like the most intuitive model, for me, is something that creates N steps, and has a keyword that controls each combination of whether the start/end values are included.  Keeping the "frames" name for a moment just for the sake of argument, I'm thinking of something like:

```
frames(<integer>, [ drop-start | drop-end | drop-both ])
```

We *might* be able to merge this into `steps()`, if we (a) come up with a good keyword for "keep both", and (b) are okay with `steps(n)` continuing to mean `drop-end` for legacy reasons.  Using a new function lets us start with "keep both" as the default, so we don't need to come up with a new keyword.  I don't have a good name for this tho; I'm still generally okay with `frames()` for gradients too. ^_^

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1301#issuecomment-310131821 using your GitHub account

Received on Wednesday, 21 June 2017 16:22:33 UTC