- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 26 Feb 2013 23:27:46 -0800
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: Liam Quin <liam@w3.org>, "www-style@w3.org" <www-style@w3.org>
On Tue, Feb 26, 2013 at 11:00 PM, Rik Cabanier <cabanier@gmail.com> wrote: > non-premultiplied gradients are not a restriction. I can't think of a single > design application or graphics library that implements this idiom. > The CSS WG introduced this so they wouldn't have to special case > 'transparent'; not because it made sense. No, we've been over this. While it's possible to hack gradients by duplicating the transparent color where the color is distributed on a line (linear, radial, and the future conical gradients all satisfy this), this stops working as soon as the color is distributed over an area, like the mesh gradients being added to SVG. We don't want to be inconsistent across our gradient types. Implementations that can't do premultiplied gradients natively can hack them by doing the transparent-color duplication behind the scenes, and then just drawing a non-premultiplied gradient. They'll have problems with mesh gradients, but I don't think Core Graphics can do mesh gradients natively anyway, so it'll require either additions to CG or some other method to implement. So, summing up, premultiplied gradients: * are more convenient for authors, because they don't produce confusing behavior due to "transparent" having an otherwise-undetectable color (like a transparent->white gradient being gray in the middle) * can't be hacked by authors when doing 2d gradients, like the mesh gradients being added to SVG2, so we should be consistent across the gradients * for the 1d gradients, can be automatically hacked by implementations that only do non-premultiplied natively, by just duplicating and coloring "transparent" color-stops behind the scenes ~TJ
Received on Wednesday, 27 February 2013 07:28:32 UTC