Re: [css-color][filter-effects] (was: Re: [filter-effects] Tainted filter primitives)

On Fri, Dec 13, 2013 at 11:44 AM, Dirk Schulze <> wrote:
> On Dec 13, 2013, at 8:11 PM, Tab Atkins Jr. <> wrote:
>> On Fri, Dec 13, 2013 at 11:05 AM, Dirk Schulze <> wrote:
>>> On Dec 13, 2013, at 7:51 PM, Tab Atkins Jr. <> wrote:
>>>> On Wed, Dec 11, 2013 at 1:07 PM, Robert O'Callahan <> wrote:
>>>>> I guess we should define in CSS Colors a "sanitized 'color' value" that is
>>>>> safe to be exposed to Web scripts, and in Filters define 'flood-color' and
>>>>> 'lighting-color' to use the "sanitized 'color' value" for currentColor
>>>> I'm fine with this.  So what all goes into it?  Color values coming
>>>> from :visited selectors, obviously, and transitively with
>>>> currentcolor.  Anything else?
>>> Looks like my previous mail didn’t get through.
>>> Why not be a bit more conservative. Since we want to expose "used values” and “active values" by CSS OM - why not let currentColor always get the same color that a “active value” property or function would return? I mean we should not differ between currentColor with “sanitized ‘color’” and another one. Just always use the  “sanitized ‘color’” for currentColor.
>> That's silly.  There's no reason to break currentcolor just because
>> :visited is being used.
> Ok, but you don’t think it is “silly” if we break currentColor sometimes?

I don't understand.

> Beside that, you broke currentColor less than a year ago when you (actually the CSS WG) changed the behavior of it. I don’t think that WebKit or Blink have ever updated the behavior since then. Therefore, it is already broken.

Whoa, way to be hostilely accusative, dude.  Maybe try backing off?


Received on Friday, 13 December 2013 20:19:37 UTC