W3C home > Mailing lists > Public > www-style@w3.org > January 2016

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 25 Jan 2016 09:56:17 -0800
Message-ID: <CAAWBYDBfAnq3qoVTJhS50T3nBysaCqE27qyThsEsOZPbV8aU5A@mail.gmail.com>
To: Simon Fraser <smfr@me.com>
Cc: Mark Straver <mark@wolfbeast.com>, www-style list <www-style@w3.org>
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.

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

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

Received on Monday, 25 January 2016 17:57:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:59 UTC