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

RE: [css3-images] Premultiplication switch

From: Brian Manthos <brianman@microsoft.com>
Date: Fri, 29 Jul 2011 17:12:30 +0000
To: Alan Gresley <alan@css-class.com>
CC: Leif Arne Storset <lstorset@opera.com>, Brad Kemper <brad.kemper@gmail.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <9710FCC2E88860489239BE0308AC5D1710C0EF@TK5EX14MBXC264.redmond.corp.microsoft.com>
Alan Gresley:
> There are other ways to do the non-premultiplied version with one
> single
> midpoint color stop.
> 
> 
>     linear-gradient(red, rgba(0,0,0,0), blue);
> 
>     linear-gradient(red, rgba(255,255,255,0), blue);
> 
>     linear-gradient(red, rgba(255,0,255,0), blue)
> 
>     linear-gradient(red, rgba(127,0,127,0), blue)
> 
> 
> The way Opera interpolates this gradient,
> 
>     linear-gradient(red, transparent, blue)
> 
> 
> suggest that internally, a double color stop (as shown below) is
> generated.
> 
>     rgba(255,0,0,0) 50%, rgba(0,0,255,0) 50%
> 
> 
> So in affect, the keyword 'transparent' is already behaving as a
> switch.

No, it's not a switch.  It's how premultiplied interpolation works.

Each of the four above "behave as if" (1) all the stops are converted to premultiplied space [which includes changing the middle stop to premultiplied-rgba(0,0,0,0)], (2) "simple math" interpolation occurs, and (3) rendering is from a "premultiplied coordinate space" brush.


At the F2F we briefly discussed having transparent "behave in some special way" where it doesn't map to a fixed value.  There are many reasons why I think this is a horrible idea that converts a specific "contained" annoyance into a contagion that infects everything involving color in CSS.

IMO, 'transparent' should remain an alias for rgba(0,0,0,0) and "interpolation issues" should be solved elsewhere.  I'd rather *remove* the keyword 'transparent' from CSS entirely than do that.
 
> > Furthermore, when currentColor is involved in your
> > gradient there is no way to translate from
> > premultiplied to nonpremultiplied.  You'd need
> > something like color-variant-opacity(currentColor, 0%)
> > as a<color>.
> 
> Just simply not allow translation from premultiplied to
> nonpremultiplied.

I don't see how this solves the problem.

Suppose I have the following:
	-a- linear-gradient(yellow, transparent);

With non-premultiplied interpolation, in the middle of the box it's grayish.

Suppose I then "fix" this by changing it to:
	-b- linear-gradient(yellow, rgba(255, 255, 0, 0));

Now I go back to my original and realize that I want currentColor rather than yellow:
	-c- linear-gradient(currentColor, transparent);

If I try to rework -b- using currentColor I get:
	-d- linear-gradient(currentColor, <how-to-I-get-transparent-currentColor>);

The issue is that there is no way to fill in <how-to-I-get-transparent-currentColor> for all values of currentColor when non-premultiplied interpolation is used.

For non-premultiplied interpolation, it simply doesn't matter because all values of r, g, and b for rgba(r,g,b,0) result in the same non-gray rendering.
Received on Friday, 29 July 2011 17:13:09 GMT

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