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

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

Simon

Received on Saturday, 23 January 2016 18:23:34 UTC