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

Re: [CSS3] support for linear-gradients & radial-gradients

From: Alan Gresley <alan@css-class.com>
Date: Sat, 05 Feb 2011 21:39:49 +1100
Message-ID: <4D4D28F5.5040503@css-class.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: Simon Fraser <smfr@me.com>, Peter Beverloo <peter@lvp-media.com>, Irfan Mir <theirf@gmail.com>, www-style@w3.org, Adrian Low <aidypoos@optusnet.com.au>, Chris Lilley <chris@w3.org>
CC W3C color expert Chris L.

On 14/01/2011 5:05 AM, Tab Atkins Jr. wrote:
> On Thu, Jan 13, 2011 at 1:39 AM, Alan Gresley<alan@css-class.com>  wrote:
>> On 13/01/2011 4:26 AM, Tab Atkins Jr. wrote:
[snip]
>> Simply that the keyword 'transparent' should not be confused with alpha
>> transparency. As it says in CSS-Color [1] for the keyword 'transparent'.
>>
>>
>>   | transparent
>>   |   Fully transparent. This keyword can be considered a shorthand for
>>   |   transparent black, rgba(0,0,0,0), which is its computed value.
>>
>>
>> So 'transparent black' is not the same as 'transparent' but the keyword
>> 'transparent' can be considered a shorthand for transparent black. CSS2.1 is
>> more explicit in suggesting that 'transparent' is not a<color>. In 14.2.1
>> [2] for background-color we have this (emphasis added).
>>
>>   | This property sets the background color of an element, either a
>>   |<color>  value *or* the keyword 'transparent', to make the underlying
>>   | colors shine through.
>
> CSS2.1 didn't have any notation for non-opaque colors, and so the
> editors apparently thought that it was easier to refer to
> 'transparent' specially.  This turned out to be a mistake,


How is this a mistake?


> and luckily
> CSS3 Color has a proper way to refer to non-opaque colors, so we can
> give 'transparent' a proper definition, which we did - it's
> rgba(0,0,0,0).


You are implying extra meaning to that part of the spec. Again.


   | This keyword can be considered a shorthand for
   | transparent black, rgba(0,0,0,0), which is its computed value.


It states that transparent can be considered a shorthand for transparent 
black. It does not say that transparent has a proper definition as being 
transparent black. If it is considered a shorthand for rgba(0,0,0,0), 
then it can also be considered a shorthand for all the other colors with 
full alpha transparency. That is 16,777,215 colors.


>>>> A transparent color does not have a point so it can not exist in any
>>>> colorspace. It does not exist as a color apart from some concept which is
>>>> very ambivalent.
>>>
>>> No, transparent colors exist perfectly fine.
>>
>>
>> I should have said that the keyword value "transparent' is not a<color>  and
>> it does not have any point in any colorspace where all values of<color>  do
>> have a points within colorspace. You use this term "transparent colors."
>> Should that really be colors with alpha transparency?
>
> Yes, 'transparent' is a color.


Really. Maybe you should read up on the definition of what color is. I 
quote from Wikipedia [1].


   | Color or colour (see spelling differences) is the visual perceptual
   | property corresponding in humans to the categories called red,
   | green, blue and others. Color derives from the spectrum of light
   | (distribution of light energy versus wavelength) interacting in the
   | eye with the spectral sensitivities of the light receptors.


Something transparent can not be visually perceived. Something 
transparent can not have an interaction with the light receptors of the 
eyes. Something transparent is outside the visible spectrum that can be 
detected by the human eyes. Gamma rays, x-rays infrared waves, radio 
waves and etc. are all forms of light that are not visible and is truly 
what can be defined as being transparent. If these were visible to human 
eyes, then they would be defined as colors. Other animals can see colors 
outsides the range of human vision. This is since such animals have eyes 
with more the three types of light sensitive receptors. This is known as 
Tetrachromacy.



> It's rgba(0,0,0,0), in the sRGBA
> colorspace (sRGB augmented with an alpha dimension).  It has a similar
> definition in all other colorspaces.


I consider this definition wrong. A colorspace is not a mathematical 
formula on a 2D plane (X and Y axis). It is something that is 3D. Below 
is a demo of sRGB colorspace with 125 colors shown in it's rightful way, 
which is 3D.

<http://css-class.com/test/css/3/transform-color-cube3.htm>

Click one of the buttons marked transparent and you are seeing sRGBA 
colorspace which occupies the same space.


>> I made a completely wrong statement. Gradients from<color>  point to<color>
>> are interpolated along a straight line in sRGB if they follow particular
>> planes within sRGB. I reason that some gradients, may travel a direct line
>> and miss precise<color>  points, in which case they use the color of the
>> nearest<color>  point (maybe rare in SRGB which has 16581376 colors). Is
>> this a fare statement to make?
>
> I'm not sure, because I don't understand what you're trying to say.


Take for instance a gradient from rgb(255,255,255) to rgb(255,255,252). 
There is no colors in that vector between these points. We can change 
another color channel and create many more such vectors like a gradient 
from rgb(255,255,255) to rgb(255,252,251). The first such gradient that 
passes through a true color point has to be precisely aligned with the 
X, Y and Z matrix.

For two axises (X, Y and Z matrix), a gradient from rgb(255,255,253) to 
rgb(255,253,255) has a midpoint of rgb(255,254,254) and for three 
axises(within a X, Y and Z matrix), a gradient from rgb(255,255,253) to 
rgb(253,253,255) has a midpoint of rgb(254,254,254).



> Yes, a color at any given point in a transition is rounded to the
> nearest whole color in practice - halfway between 'white' and 'black'
> is rgb(127.5,127.5,127.5), after all, which must be rounded up or
> down.  But that's an irrelevant implementation detail.


Halfway between 'white' and 'black' is rgb(127,127,127). We should be 
talking about steps in scalars. If each step is of 51 scalars, then we 
have these steps from black to white.

     rgb(0,0,0), rgb(51,51,51), rgb(102,102,102), rgb(153,153,153), 
rgb(204,204,204), rgb(255,255,255)



> Am I missing a more pertinent question?


No, you're just not understanding that it not just about simple rounding 
of numbers.


>>>> I don't understand why the CSS WG or implementers would want a CSS
>>>> gradient
>>>> to behave differently from a SVG gradient. A SVG gradient from<color>    to
>>>> transparent is the same as the current Gecko and WebKit implemented CSS
>>>> gradient which is interpolation in un-premultiplied space.
>>>
>>> SVG gradients don't use RGBA colors - they have RGB colors and then,
>>> separately, an opacity.  Implementations allow the SVG colors to be
>>> rgba, though, and when that occurs they want to do interpolation in
>>> premultiplied space, same as CSS.
>>
>> Can you please clarify something, so I can fully understand? Theses
>> questions are pertaining to CSS gradients.
>>
>> 1. Is a gradient from blue (#0f0) to yellow (#ff0) (midway way point is
>> #7f7f7f) interpolated in premultiplied space or un-premultiplied space?
>
> Both.  Opaque colors transition the same way in both colorspaces.


Ok, I now understanding where you coming from. You see premultiplied 
space or un-premultiplied space as some form of space. I am talking 
about 3D colorspace where you are talking about abstract mathematical 
concept of colorspace.


>> 2. Is a gradient from bluish rgba(0,255,0,0.5) to yellowish
>> rgba(255,255,0,0.5) (midway way point is rgba(127,127,127,0.5)) interpolated
>> in premultiplied space or un-premultiplied space?
>
> Both.  In general, colors with the same alpha transition the same way
> in both colorspaces.


See above and below.


> The only difference between premultiplied and non-premultiplied is
> when you're transitioning between colors with different alphas.


For me, an alpha represents a color of half it's intensity in value when 
it has opacity of 0.5 and is over a black background or an alpha 
represents a color of double it's intensity in value when it has opacity 
of 0.5 and is over a white background. I understand this.


>>> 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 not true for all colors. I think you use the word darker loosely
>> here. A gradient from blue to transparent (on a white background) get
>> gradually lighter along the full projectory of the gradient. At the same
>> time the same gradient get gradually lest saturated along the full
>> projectory of the gradient. The only thing constant is it's hue.
>
> No, I meant precisely what I said.  *All* colors get darker for the
> first half of their transition toward 'transparent' if you do the
> transition in non-premultiplied rgba space, because you're
> transitioning the color components toward black.


A gradient from blue to transparent over a white background get lighter 
along it path. I talking about lighter as in HSL. See line 7 with Blue ~ 
Transparent.

<http://css-class.com/test/css/colors/grayscale2.png>


So your expertise in maths does not reflect an observable reality.


> That is, the halfway point between 'blue' and 'transparent' in
> non-premultiplied rgba space is rgba(0,0,127,.5).  On the other hand,
> the halfway point in premultiplied rgba space is rgba(0,0,255,.5).


There we go. I now have the answer. Thank you Tab. Please note that you 
have '127' which is '7f'. What happened to the '127.5'?


> The former is clearly darker than the latter, for the same reason
> rgb(0,0,127) is clearly darker than rgb(0,0,255).


You can not use this analogy since non-premultiplied rgba space is 
curved and premultiplied rgba space is linear when going from color to 
transparent in sRGB colorspace. The darkness or lightness observed is 
determined by the HSL(A) values of a background color behind what is 
partially transparent.


> Now, even though the color is darkening, the final pixel color you see
> after compositing it onto the background color may indeed be lighter,
> depending on the background.  That's irrelevant.


No it is not. I am a former artist who first experimented with color 
pigment with primaries of red, blue and yellow. Using color pigment on 
white paper or black paper has a greatly difference appearance and is 
far from being something considered irrelevant. What I find with color 
generated by light or a display device that can show sRGB is that the 
whole ways that colors interact is reversed.


> You've confused
> yourself by thinking about the final pixel colors before; what matters
> is the actual colors being used, not what you get after you composite
> all of them together.


I'm not confused. You are understating the significance of the final 
color when they are composite all together.


[snip]
>> I would really like to see both types of gradients (<color>  to transparent)
>> with non-premultiplied and premultiplied interpolation in CSS.
>
> As far as I can tell, there's no benefit to authors from being able to
> transition in non-premultiplied space.  It does the wrong thing in the
> general case.


Then your general case is theoretically 1/64 of all possible cases. You 
are wanting to avoid the affect on 1/64 of all possible cases where I am 
wanting to avoid the affect on 63/64 of all possible cases.

I say this since a gradient of white to transparent over a white 
background (final composite color) is rgb(191,191,191) which is 1/4 of 
each color channel.


Not allowing the current behavior will break the affects seen here.

<http://www.marcofolio.net/webdesign/pure_css3_bokeh_effect_with_some_jquery_help.html>

And break what is seen here with the various colored backgrounds.

http://css-class.com/test/css/colors/gradient-white-trans2.htm



1. <http://en.wikipedia.org/wiki/Color>
2. <http://en.wikipedia.org/wiki/Tetrachromacy>



-- 
Alan http://css-class.com/

Armies Cannot Stop An Idea Whose Time Has Come. - Victor Hugo
Received on Saturday, 5 February 2011 10:40:30 GMT

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