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

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

From: Sebastian Zartner <sebastianzartner@gmail.com>
Date: Fri, 8 Apr 2016 15:25:46 +0200
Message-ID: <CAERejNY_pFhenmf=nDf6xe+3zah3JW+JKv=RbN2wJgRAHRumEA@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Xidorn Quan <quanxunzhen@gmail.com>, Simon Fraser <smfr@me.com>, Mark Straver <mark@wolfbeast.com>, www-style list <www-style@w3.org>
As I stumbled over this issue again today and saw that there was no
final conclusion on this after rereading the whole thread, I'd like to
revive it.

On 26 January 2016 at 01:11, Rik Cabanier <cabanier@gmail.com> wrote:
>
> On Mon, Jan 25, 2016 at 3:48 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>
>> On Mon, Jan 25, 2016 at 3:29 PM, Xidorn Quan <quanxunzhen@gmail.com> wrote:
>> > On Tue, Jan 26, 2016 at 6:22 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> >> On Mon, Jan 25, 2016 at 11:17 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>> >>> 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:
>> >>>> > 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.
>> >>
>> >> Then that's a bug, either in the specs or the implementations.  There
>> >> is absolutely no reason a color should serialize differently based on
>> >> whether it's bare or wrapped in a gradient function.
>> >
>> > Given all impls current agree with the same behavior here, I guess we
>> > can probably make 'transparent' a keyword value in gradient function
>> > to simulate premultiplied effect, and revert the general cases to
>> > non-premultiplied...
>>
>> If and only if there's not a significant number of gradients out there
>> that currently write out transparent with rgba() syntax, or that use
>> near-transparent colors that'll significant change behavior here.
>
> Given that a major browser has a different implementation and no bug reports, that number is likely small.
> Also, when we made the change in the other browsers, there were no user reported bugs that we closed.

Could we get some statistics for the usage of rgba(0,0,0,0) instead of
'transparent' in gradients and color animations?
(Note that transitions between semi-transparent or opaque black and
rgba(0,0,0,0) need to be excluded.)

>> And we (Blink) must store the input string somewhere so we can output
>> it back literally, because I *know* that we parse that into an
>> #AARRGGBB 4-byte int and operate on it like that.  So it doesn't
>> matter whether you type "transparent" or "rgba(0,0,0,0)", you get
>> 0x00000000 either way.
>
>
> It looks like Safari, Edge and Chrome return the original CSS input string.
> Firefox resolves color names to their rgba equivalents, but not 'transparent'

On 25 January 2016 at 18:56, 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.

Given Rik's observations, this claim is incorrect, at least for gradients.

FWIW I agree with Mark and Rik that 'transparent' should be special
treated to mean transparent for the previous and next color instead of
transparent black.
So linear-gradient(red,transparent,blue) results in four color stops
rgba(255,0,0,1) @ 0% -> rgba(255,0,0,0) @ 50% -> rgba(0,0,255,0) @ 50%
-> rgba(0,0,255,1) @ 100%.

Also, I believe this topic is something that's worth to be discussed
in a CSSWG conf call or F2F, so we can get a proper resolution for it.

Sebastian
Received on Friday, 8 April 2016 13:26:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC