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

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

> On Mon, Jan 25, 2016 at 10:53 AM, Rik Cabanier <cabanier@gmail.com> wrote:
> > 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.
>
> By the time rendering code sees the value, it's been computed.
>
> > 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.
>
> Sure it does.  (Or it should be doing so, for consistency - colors
> should be computed in computed values.)


It does not. I tried Edge, Safari 9, latest Chrome and Firefox.


>
> >> 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.
>
> In my own testing in the past, I only needed a few stops.  You need
> more if you're manually arcing a path *in fully opaque colors*, but
> it's hard to see seams in the mostly-transparent sections.


For darker colors, maybe. The eye picks up even subtle stepping in light
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.
>
> That's possible.  What of it?
>

Just saying that this should be tested to make sure it doesn't look weird.


> (The underlying discussion of "can we change the behavior of today's
> gradients" is almost certainly no, regardless of what details we
> quibble over.)


I was resigned to that because I thought all browsers were in agreement.
With Safari being the exception and another advocate, my hopes are up again
:-)