[csswg-drafts] [css-ui-3] caret-color animations, 'auto' and 'currentColor'

frivoal has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [css-ui-3] caret-color animations, 'auto' and 'currentColor' ==
The `auto` and `currentColor` values of the `caret-color` property 
compute to themselves as a keyword, rather than to an RGB(A) value, 
because otherwise that would mess with inheritance.

However, (unless I am misunderstanding how transitions and animations 
work) this also means that you cannot smoothly transition or animate 
between`auto` or `currentColor`  and another color.

While it is not the end of the world, it seems a little unfortunate. 
Code like this for example, while probably not a major use case, 
doesn't look unreasonable, and it'd be nicer if the transition worked 
without discontinuity:
```css
.foo {
  color: initial; /* or whatever */
  caret-color: auto;
  transition: all 1s;
}
.foo:hover {
  color: green;
  caret-color: lime;
}
```

Preserving sanity of inheritance is much more important than that, but
 @mrego ’s first try and implementing `caret-color` in Blink actually 
got both: for inheritance and `getComputedStyle()` purposes, `auto` 
and `currentColor` compute to themselves as keywords, but at the same 
time, they still animate.

Is the ability to do that unique to Blink's internals, or can other 
browsers do it too? Do we have a concept in the spec that allows to 
express this? If yes to both, should we do it? Did I misunderstand 
something?

Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/781 using your GitHub 
account

Received on Thursday, 1 December 2016 06:21:44 UTC