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

On Dec 13, 2013, at 8:11 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:

> On Fri, Dec 13, 2013 at 11:05 AM, Dirk Schulze <dschulze@adobe.com> wrote:
>> On Dec 13, 2013, at 7:51 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Wed, Dec 11, 2013 at 1:07 PM, Robert O'Callahan <robert@ocallahan.org> 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?

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.

Greetings,
Dirk

>  Plus, depending on implementation strategy,
> actually getting the sanitized color is expensive (as you have to
> rerun style matching, excluding all rules with :visited in their
> selectors).
> 
> ~TJ