W3C home > Mailing lists > Public > public-css-archive@w3.org > May 2017

[csswg-drafts] [css-images] Add easing functions to color stops

From: Eric A. Meyer via GitHub <sysbot+gh@w3.org>
Date: Mon, 08 May 2017 16:10:41 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-227096597-1494259840-sysbot+gh@w3.org>
meyerweb has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-images] Add easing functions to color stops ==
A recent CSS-Tricks article (https://css-tricks.com/easing-linear-gradients/) and subsequent Twitter discussion (https://twitter.com/stubbornella/status/861603397677359104) spurred me to file this request for Level 4.

In summary, linear gradients are not always visually acceptable.  This is particularly true when “fading out” a dark color to transparent.  The article describes how to set up a bunch of color stops to ease out the gradient.  A much better solution would be to add easing functions to all color stops after the first, with a `linear` default for backward compatibility.

The example in the article could be approximated like this:

```
linear-gradient(to bottom, black 0%, transparent 100% ease-in-out);
```

…instead of the 11 color stops used to get the effect.  (Note that I don’t claim this would be a precise match; a `cubic-bezier()` easing would most likely be required for that.  But it would be close.)

This would change the definition of `<color-stop>` from:

```
<color-stop> = <color> <length-percentage>?
```

…to the following at a minimum:

```
<color-stop> = <color> <length-percentage>? <timing-function>?
```

As an author, I would probably prefer:

```
<color-stop> = <color> [ <length-percentage> || <timing-function> ]?
```

…since that would allow me to write the easing and distance in whichever order I liked.  (For that matter, I’d prefer to be able to write all three in any order, but I don’t know if that would upset any implementors’ apple carts.)

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/1332 using your GitHub account
Received on Monday, 8 May 2017 16:10:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 10:12:53 UTC