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

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

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

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

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

~TJ

Received on Monday, 25 January 2016 18:58:52 UTC