W3C home > Mailing lists > Public > public-css-archive@w3.org > August 2021

[csswg-drafts] Pull Request: [css-easing-1] Some ideas for linear() easing

From: Jake Archibald via GitHub <sysbot+gh@w3.org>
Date: Fri, 20 Aug 2021 15:12:19 +0000
To: public-css-archive@w3.org
Message-ID: <pull_request.opened-716813034-1629472337-sysbot+gh@w3.org>
jakearchibald has just submitted a new pull request for https://github.com/w3c/csswg-drafts:

== [css-easing-1] Some ideas for linear() easing ==
This is an attempt to make some progress on custom easing functions, specifically https://github.com/w3c/csswg-drafts/issues/229#issuecomment-861247074

I've never edited a CSS spec before, so I don't really know what I'm doing. Sorry if this isn't helpful in any way. Here's what I'm trying to do:

There's already a `linear` keyword. I figured we could overload that, so `linear` is a shorthand for `linear()`.

If `linear()` is called without arguments, it's an identity easing.

`linear()` can be given stop points, like:

```
linear-easing(0 0, 0.1 0.2, 0.3 0.4, 0.7 0.6, 0.8 0.8, 1 1)
```

…where each pair is a value followed by a progress position. The progress position can be omitted:

```
linear-easing(0, 0.1, 0.3, 0.7, 0.8, 1)
```

…in which case it's automatically assigned, similar to gradient stop points.

Position values can be negative and greater than 1, but will typically be 0-1.

If an input progress value is less than the position of the first stop point, the value of the first stop point is used.

If an input progress value is greater than the position of the final stop point, the value of the final stop point is used.

Unfortunately this means that `linear()` is different to `linear(0, 1)`, as the former is a pure identity function, whereas the latter clamps when given values outside 0-1. Maybe there's a better way of handling that?

See https://github.com/w3c/csswg-drafts/pull/6533


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 20 August 2021 15:12:20 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:42 UTC