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

FWIW
Here's the discussion we had on the subject during TPAC:
https://lists.w3.org/Archives/Public/www-style/2012Nov/0262.html under
Transitions/solved. The minutes are unfortunately bad.
Note that dbaron's assumption that Firefox implemented them was incorrect
at the time.

On Sun, Jan 24, 2016 at 5:22 AM, Mark Straver <mark@wolfbeast.com> wrote:

> On 24/01/2016 06:37, Rik Cabanier wrote:
> > The graphics frameworks in the browsers all interpolate in
> non-premultiplied
> data. I had to add emulation code to all the browsers to make this happen.
>
> So there's even less of a reason then to not change this...
> Sorry to hear that so much extra work has been put into something that
> could
> have been solved with the proposed approach the first time.
>
> > Like Mark, I proposed to treat transparent special but it fell on deaf
> ears
> > [1]. I remember Tab and dbaron especially being opposed.
> > Unfortunately, now that Ion and I made all browsers compliant, it's
> likely too
> > late to make this change
>
> I don't think it's ever too late to make an improvement to a spec that is
> beneficial for all involved and has no negatives. This is done all the
> time on
> other specs, so why not here?
>
> I understand that this might impact certain websites that explicitly rely
> on
> premultiplied colors, but the common case (fade to transparent) would not
> be
> affected.
> It would need 2 changes to the spec:
> 1. Change the definition of "transparent" as a keyword to not be a
> shorthand
> for rgba(0,0,0,0) but rather a transparent version of the adjacent color
> 2. Change the color space to use to be non-premultiplied RGBA
>
> For the record, I've looked at implementing this special case for
> 'transparent' in my Mozilla-derived browser and it was *very* simple to
> do. I
> gather all implementations in browsers would use a list (e.g. array or
> linked
> list) of stops; all it takes is changing the "transparent" stop from
> "transparent black" to the adjacent color value (previous or next) with
> opacity 0. If transparent is "in the middle" is the only time the list
> length
> changes because it needs to have a new stop inserted. I'm sure that
> inserting
> an element into an existing list is something all implementations can do :)
>

It's slightly more complicated.
You need to substitute transparent with 2 coincident stops of the previous
*and* the next color.

Removing the premultiplied calculations is indeed easy: remove the hacky
code that adds premultiplied simulation.