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

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:
> >
> > Hello people,
> >
> > After some discussion in the Mozilla bugzilla [1] system I gathered this
> was a
> > better place to bring this up, since it seems to be a spec bug, at least
> in
> > part as a result from prior discussion in bugzilla. [2]
> >
> > The specification for color stops in gradients states:
> >
> > "At each color stop position, the line is the color of the color stop.
> Between
> > two color stops, the line’s color is interpolated between the colors of
> the
> > two color stops, with the interpolation taking place in premultiplied
> RGBA space."
> >
> > There's a problem with using premultiplied RGBA space since it only
> caters
> > specifically to transitioning from fully opaque to fully transparent (and
> > dodging the undesired effect that the 'transparent' keyword is a
> shorthand for
> > only "transparent black" of the full range of transparent colors
> available).
> > The problem is that, as far as I know, it's *impossible* in
> premultiplied RGBA
> > space to get a linear gradient transition in both color and opacity,
> since the
> > color is directly tied to the opacity of the color stop.
> >
> > e.g. linear-gradient (to bottom, rgba(255,255,0,1), rgba(255,0,0,0)) will
> > completely ignore the color of the target stop because it has opacity 0.
> One
> > can argue that a fully transparent color has no color, but it also
> influences
> > partially transparent color stops.
> > If the opacity of the target stop was, say, 0.1, then you'd only get a
> > proportional amount of red in the gradient to the opacity value -- this
> is
> > *not* a linear interpolation between both colors that one would expect
> from
> > the CSS statement.
> >
> > 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 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.
>

You have it reversed. 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.

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

1:
http://w3cmemes.tumblr.com/post/34628700024/when-worf-says-transparent-he-means