W3C home > Mailing lists > Public > www-style@w3.org > July 2011

Re: [CSS3-color] [css3-images] [css3-transitions] transparent transitions

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Fri, 8 Jul 2011 11:02:08 -0700
Message-ID: <CAAWBYDDRrFF5NddALGON1HUUoxtzV35=kVUcNTBG6A+-1dU_nQ@mail.gmail.com>
To: Alan Gresley <alan@css-class.com>
Cc: fantasai <fantasai.lists@inkedblade.net>, www-style@w3.org, Tantek Çelik <tantek@cs.stanford.edu>
On Fri, Jul 8, 2011 at 12:48 AM, Alan Gresley <alan@css-class.com> wrote:
> On 29/06/2011 4:27 AM, Tab Atkins Jr. wrote:
>> On Mon, Jun 27, 2011 at 10:46 AM, fantasai
>> <fantasai.lists@inkedblade.net>  wrote:
>>> On 01/12/2011 12:26 PM, Tab Atkins Jr. wrote:
>>>> What you're seeing is the fact that transitions from opaque colors to
>>>> transparent in non-premultiplied space get darker as they progress.
> This is a blanket assertion. Does this gradient get darker as it progresses.
>  background: linear-gradient(black, rgba(255,255,255,0.0))
>>>> Try doing a transition from opaque white to transparent over a white
>>>> background, and you'll see it very clearly
> This is true as long as I continue to have the same background-color. The
> below gradient composite on a white background does not get darker.
>  background: white linear-gradient(black, rgba(255,255,255,0.0))

I said "transparent", meaning the keyword.

> So apart from this suggested change affecting transparent-black, any
> gradient with a transition to transparent-white are also broken along with
> transitions to the other 16,777,214 transparent color points apart from ones
> that behaves as a gradients in premultiplied space similar to this one.
>  linear-gradient(white, rgba(255,255,255,0.0))

I don't understand what you're trying to say here.

>>>> - you'll get an image that
>>>> starts white, darkens to gray
> Actually transparent-gray rgba(127,127,127,0.5).
>>> , and then lightens to white again.
> It's not white and it _does not lighten_ since it's color is also decreasing
> along with the alpha before it becomes transparent-black composite over a
> white background. What you are saying is white is actually the white of the
> white background-color, not the gradient.

I'm clearly talking about the image here (thus my use of the word
"image"), or the final composited color.  Why would you assume that I
mean the actual gradient goes back to white, when that's clearly and
trivially incorrect?

>>> Is there a way to avoid things like this? It seems to me that having
>>> 'transparent' mean 'transparent black' means you almost never get what
>>> you want, which is the opacity fading without the color itself changing.
>>> I think that's a common enough use case that it should be easy to do.
>> dbaron's got it - Image Values requires gradients to transition in
>> premultiplied space for precisely this reason.
> What reason? The supposed reason is based on a problem that never existent.
> Can you clearly state a problem or an issue?

The problem is stated clearly in the quote that I was responding to
there: "having 'transparent' mean 'transparent black' means you almost
never get what you want... I think that's a common enough use case
that it should be easy to do.".

>> Premultiplied
>> transitions are identical to non-premultiplied when you hold either
>> the alpha or the color steady, and they're generally more attractive
>> when both the color and alpha change at the same time.
> This is incorrect. Are these identical?
>  background: white linear-gradient(rgba(255,255,255,0.5),
> rgba(255,255,255,0.0));
>  background: white linear-gradient(rgba(255,255,255,0.5),
> rgba(127,127,127,0.5));

I don't understand.  I didn't say that those two were identical.  I
stated that, for each of those gradients, you get the exact same
result whether you transition in premultiplied or non-premultiplied
space.  The difference only arises when you're changing both the color
and the alpha at the same time, and the premultiplied behavior is
usually more attractive.

Received on Friday, 8 July 2011 18:03:04 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:47 UTC