Re: [csswg-drafts] [css-easing-1] Some ideas for linear() easing (#6533)

@tabatkins 

> Syntax nit: I'd probably use a % for the progress value. That accords better with things like gradients, and makes it _much_ clearer which value is progress and which is the value:
> 
> `linear(0 0%, 0.1 20%, 0.3 40%, 0.7 60%, 0.8 80%, 1 100%)`

I had the same thought, but here's why I ended up with two numbers: Both values are the same type, that's how the simple identity version of the `linear` works. So, they could both be %, or both be numbers. I went with numbers because that's what the spec already uses for cubic-bezier and [all the diagrams](https://drafts.csswg.org/css-easing/curve-keywords.svg).

I agree it _looks_ better with different types, but I'm not sure it makes sense. If we go with one value being a number, and the other being a %, I guess we should update the diagrams in the spec too to reflect that.

> It also means we wouldn't necessarily have to impose an ordering, since the types are distinguishable.

This gets really weird when trying to generate auto values for input position. I think it's why gradient syntax doesn't allow it (well, if one percent is less than the previous one, it makes it equal to the previous one). Being consistent with gradient syntax here seems better.

> I _really_ don't like the different behavior between `linear()` and `linear(0,1)`. If we just always made <0 and >1 extend using the first/last segment, you could achieve the clamping behavior with `linear(0 calc(infinity * -1%), 0 0%, 1 100%, 1 calc(infinity * 1%))`. We could probably add some syntax to make that easy and explicit instead, like `linear(0 0% fill, 1 100% fill)`, where the `fill` keyword is only valid on the first/last value, and has the same approximate meaning as `animation-fill-mode`.

We could borrow more from gradient syntax here:

```css
.whatever {
  background: linear-gradient(to right, red 20%, orange 20% 40%, yellow 40% 60%, green 60% 80%, blue 80%);
}
```

Here, `orange 20% 40%` effectively creates two 'orange' points, one at 20% and one at 40%. We could do the same.

```css
.whatever {
  /* No clamping */
  animation-timing-function: linear(0, 1);
  /* Clamping */
  animation-timing-function: linear(0 0 0, 1 1 1);
}
```

The latter creates 4 points, two where the input and output are 0, and two where the input and output are 1. Having two points means the values would 'extend' flatly. This makes it relatively easy to clamp just one side of the easing.

The syntax also allows for creating a 'rest' period during the easing:

```css
.whatever {
  animation-timing-function: linear(0, 1 .25 .75, 0);
}
```

> I don't think the spec needs to be _quite_ as algorithmic as written here

That's my lack of experience with CSS specs showing :smile:

-- 
GitHub Notification of comment by jakearchibald
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/6533#issuecomment-903086012 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 21 August 2021 09:01:12 UTC