W3C home > Mailing lists > Public > www-style@w3.org > September 2010

Re: [css3-images] Gradients feedback

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 08 Sep 2010 15:00:36 -0400
Message-ID: <4C87DD54.60105@mit.edu>
To: Alan Gresley <alan@css-class.com>
CC: www-style list <www-style@w3.org>
On 9/8/10 7:38 AM, Alan Gresley wrote:
> Ok, here we go. In sRGB space, all colors are fully opaque so any
> gradient that goes from one point to another point within the sRGB space
> will be a gradient of fully opaque color.

Yes.  As long as all colors are fully opaque, premultiplied and 
un-premultiplied alpha behave exactly the same way, note.

> You would like the midway point between a gradient between yellow and
> transparent to also be #ff7

No, I would like a gradient halfway from #ff0 to transparent to be 
rgba(255, 255, 0, 0.5).

In un-premultiplied space, what you get instead is rgba(127, 127, 0, 0.5).

> or to been non-premultiplied but this would
> mean that all colors (points) within sRGB space that are gradients to
> transparent would have to be somewhat non-premultiplied. I don't know
> how this can be done.

I have no idea what you're trying to say there.

> To explain the precise mathematics, I will use the example of the
> gradient between yellow and transparent. The current midway point as
> implemented by Gecko and WebKit is #bb7 (fully opaque).

No.  The current midway point as implemented by Gecko is rgba(127, 127, 
0, 0.5).  I can't speak to what webkit does authoritatively, but the 
rendering in Webkit looks identical to Gecko's (see below).

Note that _if_ you happen to composite rgba(127, 127, 0, 0.5) on top of 
white you will get something like #bebe7f.  So if your "precise 
mathematics" is coming from applying a color picker to the results of 
compositing a gradient from yellow to transparent onto a white 
background I can see you getting the numbers you get.

Testcase that shows that the gradient's intermediate points are not in 
fact opaque in either engine:

<!DOCTYPE html>
<style>
   div { width: 100px; height: 100px; }
   div.g {
         background: -moz-linear-gradient(yellow, transparent);
         background: -webkit-gradient(linear, center top, center bottom,
                                      from(yellow), to(transparent));
   }
</style>
<div style="background: white"><div class="g"></div></div>
<div style="background: red"><div class="g"></div></div>

> This same color #bb7 is also the midway point of the gradient from #770 to white.

Yes, but that's an accident of happening to composite onto a white 
background.  See above.

> Using another example, the gradient between blue and transparent. The
> current midway point as implemented by Gecko and WebKit is #77b (fully
> opaque).

Again, no.  The current midway point is rgba(0, 0, 127, 0.5). 
Compositing that onto a white background gives #7f7fbe, which is what 
you seem to have measured with your color picker.

> This all changes when the background behind the element with the
> gradient is not white.

Nothing about the _gradient_ changes.  All that changes is what it's 
composited against.  Given that you made this observation, I'm not sure 
how you can claim with a straight face that the intermediate gradient 
colors are "fully opaque".

>> Computing gradients in premultiplied space makes gradients to
>> transparent work much better. In non-premultiplied space they all
>> look black-ish in the middle.
>
> Yes, it does look grayish or blackish but this is because our eyes have
> difficulty see a light hue on a light background.

No, it's because you're desaturating the color in addition to changing 
its opacity value if you transition to rgba(0,0,0,0) in unpremultiplied 
space.

> The yellow lines shows the color (mapped to sRGB space) when the
> background is white.

Gradients need to be defined independently of what they're being 
composited onto.

> I hope this all makes some sense.

The part starting with the link to graphic doesn't sorry...

-Boris
Received on Wednesday, 8 September 2010 19:01:10 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:31 GMT