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

On Fri, Apr 8, 2016 at 6:25 AM, Sebastian Zartner
<sebastianzartner@gmail.com> 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.

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

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.

This sort of magic behavior has lots of bad knock-on effects.

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

~TJ

Received on Friday, 8 April 2016 14:57:07 UTC