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

On Mon, Jan 25, 2016 at 9:56 AM, Tab Atkins Jr. <jackalmage@gmail.com>
wrote:

> On Sat, Jan 23, 2016 at 10:23 AM, Simon Fraser <smfr@me.com> wrote:
> > On Jan 22, 2016, at 10:12 am, Mark Straver <mark@wolfbeast.com> wrote:
> >> I suggest a spec adjustment to make the 'transparent' keyword a special
> case
> >> instead of just a simple shorthand, and make gradients work in
> >> un-premultiplied RGBA space to allow proper transparent gradients to be
> >> constructed.
> >> For example, the 'transparent' keyword could be handled as an inherent
> stop of
> >> the adjacent color with opacity 0 (on either side), or 2 stops if
> transparent
> >> is somewhere "in the middle" of a gradient definition with each stop
> having
> >> the color of the adjacent stop in that direction. This would avoid the
> "black"
> >> transition that would otherwise occur with a simple shorthand.
>
> 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.
>

This proposal wouldn't change how the computed value of transparent
changes. This is an under-the-hood change in the rendering code.
Are you worried about the computed value of the 'transparent' keyword in
the gradient? If so, that one doesn't resolve to an rgba color.


> Premultiplied just makes some paths easier than non-premultiplied (and
> the reverse is true as well).  You can still approximate an

"independent" transition of color and opacity by manually arcing the
> gradient through the color space; you only need 3-4 stops to get
> something generally indistinguishable from an unpremultiplied
> transition.
>

That is not true. If you go from 0-100, you will need 9 stops to avoid
seams with lighter colors. Moreover, I have no idea what the result will
look like by emulating CSS on top of the emulating C++. It potentially
could create a hundreds of stops under the hood.


> > This has been discussed several times in the past; we all agree that
> interpolating in non-premultiplied colors
> > is better, but this is not supported by the graphics frameworks on some
> platforms (e.g. by CoreGraphics on Mac)
> > so the spec is not able to mandate it.
>
> Wait, what? No, the *exact opposite* is true.  I switched the spec
> over to doing premultiplied *over some people's objections* because it
> gave better results in the common case.  The vast majority of
> gradients to/from transparent just want the premultiplied result (they
> don't think of it that way, but they want the "yellow goes
> transparent" behavior, rather than "yellow turns kinda grayish as it
> goes transparent" behavior).
>
> If we had had a way to specify opacity independently from the color in
> gradients (and it was as natural as saying "transparent"), then we
> possibly could have kept gradients in unpremultiplied space.  But that
> didn't happen, so eh..
>
> ~TJ
>
>