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

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

From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
Date: Sat, 21 Aug 2021 16:43:45 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-903142936-1629564223-sysbot+gh@w3.org>
> I feel we should keep the key word linear-easing(....)

The reason I don't like having `-easing()` in the name is because the existing easing keywords and functions don't use that suffix either. A *custom* easing (as in, backed by JS or something as a Houdini API) would probably need a name like `custom-easing()`, but for the built-ins, `linear-easing()` looks a little weird alongside `linear`, `ease-in`, and `steps()`.

> I don't think we should complicate the linear-easing function with fillModeI don't think we should complicate the linear-easing function with fillMode

I'm not saying it interacts with fill mode. I'm saying that we can use the *analogy* of fill mode for the keyword that extends the linear easing backwards/forwards infinitely. There might be a better keyword, it was just my first suggestion.

> 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.

cubic-bezier isn't *quite* doing percentages, tho. (well, all numbers are percentages, just with the decimal point moved, but you know what I mean)  Placing points between "start" and "end" *is* a percentage, tho, and we use that type to indicate the exact same semantic for animations and gradients. We should stick with it, both for consistency *and* readability. (I literally couldn't tell what value was which in your example, and had to read your prose to figure out that you meant for the progress values to be evenly spaced, meaning the .2/.4/.6/.8 must be the progresses.)

> 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.

Sorry, you misunderstood me. Using different types means that ordering *in each pair* doesn't need to be specified - you could write `20% .3` or `.3 20%`. Between pairs we obviously still need ordering, for all the reasons you give.

> [stuff about doubling up progress value]

Yeah that works nicely, and I agree that in general having doubled progresses is useful just as it is for gradients. We'd need to call this technique out explicitly in the spec as a way to get "flat" values at the start/end, but I like when things come for free. ^_^

Note that this makes the values *even less readable* when they're all the same type; percentages are an absolute necessity here.

GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/6533#issuecomment-903142936 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 16:43:47 UTC

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