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

Adding agenda+ since we need to resolve this issue soon. This feature has reached Firefox beta and will ship on the release channel in early August. I expect Chrome is not far behind. Beyond that point it will be much harder to change this naming.

To summarize the issue:

* We initially decided to use `frames()` since:
  * It has slightly different behavior to `steps()`, namely values of `n` less than 2 are invalid.
  * There was strong community support for this name (the proposal itself came from Martin Pitt via the [Animation at Work slack](https://damp-lake-50659.herokuapp.com/)). That this naming makes sense to many people has been been subsequently confirmed by Rachel's informal twitter poll.
* Since then the TAG [raised concern](https://github.com/w3ctag/design-reviews/issues/161#issuecomment-297617664) about semantic overlap with animation frames (`requestAnimationFrame`) and keyframes (`@keyframes` etc.).
* Subsequent to that interest has been expressed in using timing functions for gradients where `frames()` is a less suitable name (#1332).
* Furthermore, there appears to be interest in coining a fourth variation on step timing functions where *neither* of the endpoints are included (#1371).

Since I will not be able to attend telcon this week (I can only attend the APAC-friendly telcons), I'll leave my take on the issue here:

* Given the last two points in particular, I think we *should* rename this by simply extending `steps()` somehow.
  * Having `frames()` and possibly yet another timing function which are only subtly different to `steps()` but have completely different names feels like a unnecessary platform wart that will make learning this syntax harder for authors (when you realize that `steps(2, start)` doesn't do what you want, it's much more natural to reach for something that looks similar) and that we will regret later.
  * Sticking `frames()` in a gradient also seems odd.
* Strawman 1:
  * Recognize that the existing `start` and `end` refer to where the step happens and *not* which endpoints are included. So in keeping with that precedent:
  * `steps(n, start)` — n ≥ 1
  * `steps(n, end)` — n ≥ 1
  * `steps(n, inside)` — n ≥ 2 (= `frames(n)`, i.e. the steps are inside the interval)
  * `steps(n, outside)` — n ≥ 2 (neither endpoint is included)
* Strawman 2:
  * Forget trying to be consistent with `start` and `end` and try something that might be less mathematically consistent but is more intuitive.
  * `steps(n, start)` — n ≥ 1
  * `steps(n, end)` — n ≥ 1
  * `steps(n, distribute)` — n ≥ 2 (= `frames(n)`, i.e. "distribute the steps evenly within the interval")
    * Alternatively, `space` (space apart)? `equal` (equally distributed)?
  * `steps(n, clip)` — n ≥ 2 (neither endpoint is included, i.e. clip off the endpoints)
    * Alternatively, `trim` (trim the gap between the steps and interval ends)? `align` (align steps with ends of interval)
* At this stage I prefer strawman 2. If there is concern about the range of `n` differing between the different versions, then I'd still prefer a name that is obviously related to `steps()`, e.g. `steps-distribute(n)` and `steps-clip(n)`. (There are subtle differences between how `steps()` and `frames()` handle values at the endpoints that might be easier to preserve with different function names so I don't mind this option either.)

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

Received on Tuesday, 20 June 2017 00:31:54 UTC