Re: [css-images] Negative implications of linear gradient color space choice in CSS

On 8 April 2016 at 16:56, Tab Atkins Jr. <> wrote:
> On Fri, Apr 8, 2016 at 6:25 AM, Sebastian Zartner
> <> wrote:
>>> This wouldn't be backwards-compatible - "transparent" currently
>>> computes to rgba(0,0,0,0) and lots of code in the wild depends on that
>>> (specifically, it depends on always getting an rgba() result out of
>>> getComputedStyle()), and any change would break things.
>> Given Rik's observations, this claim is incorrect, at least for gradients.
> And that's a serialization bug.  We're not putting special
> color-serialization behavior into the specs for one particular
> function.

We're talking about the 'transparent' keyword, not a particular function.

>> FWIW I agree with Mark and Rik that 'transparent' should be special
>> treated to mean transparent for the previous and next color instead of
>> transparent black.
>> So linear-gradient(red,transparent,blue) results in four color stops
>> rgba(255,0,0,1) @ 0% -> rgba(255,0,0,0) @ 50% -> rgba(0,0,255,0) @ 50%
>> -> rgba(0,0,255,1) @ 100%.
> This would mean that transparent is *not* equivalent to any RGBA
> color, and has to be maintained as a special keyword all the way
> through to the end of the value pipeline; even currentcolor resolves
> to something RGBA at used-value time.

Correct. And regarding its serialization there are two solutions:
1. Maintain the 'transparent' keyword (as it's currently done in all
cases in Firefox and Edge and for gradient functions in Chrome and
2. Serialize it into one or two RGBA colors as shown in the example.

> This has multiple, significant effects on animation, too.
> "transparent" is no longer an animatable value (impossible to smoothly
> move from it to any other color), so any gradient using "transparent"
> stops being animatable too. To make it animatable, you have to
> manually put in the two RGBA steps, which means you have to double-up
> that step for any other gradient you're animating with this one.

The same rules for gradient color transitions apply to animations. So
it would still be animatable.
Reusing the example from above the transtion between the colors would
be rgba(255,0,0,1) @ 0% -> rgba(255,0,0,0) @ 50% -> rgba(0,0,255,0) @
50% -> rgba(0,0,255,1) @ 100% for an animation like this:

@keyframes example {
  0% {
    background-color: red;
  50% {
    background-color: transparent;
 100% {
    background-color: blue;

>> Also, I believe this topic is something that's worth to be discussed
>> in a CSSWG conf call or F2F, so we can get a proper resolution for it.
> We officially resolved on premultiplied colors years ago.

Ah, right, two resolutions actually: (Use
premultiplied colors for gradients and transitions.)
(Animations of colors are in pre-multiplied space.)

Reasoning for the latter was consistency with gradients.
In the former minutes you said that you "don't want to make
transparent magic", while you later even mentioned the example I wrote
above regarding special-casing 'transparent' in non-premultiplied
color transitions. Though nobody reacted to that.
>From that, two conclusions can be drawn. Either there was silent
agreement with your statements or treating 'transparent' special
wasn't actually considered by the others back then.

So, this is then a request to revise the former resolutions.
Reasons for non-premultiplied color transitions with special-casing

Reasons for non-premultiplied color transitions with special-casing
- Allow more appealing (and presumably more expected) color transitions
- Avoid the ugly grayish effect
- Make it easy to achieve premultiplied and non-premultiplied
transitions (avoiding approximations)
- Gets rid of "hacky code that adds premultiplied simulation"

Reasons against it:
- Implementations need to be changed again and get more complicated
related to 'transparent'
- Causes display issues where rgba(0,0,0,0) is used instead of 'transparent'


Received on Friday, 8 April 2016 23:13:10 UTC