Re: [css-color][css-transitions] Interpolation between currentcolor keyword and actual color value

On Friday 2016-04-22 12:25 -0700, Tab Atkins Jr. wrote:
> On Fri, Apr 22, 2016 at 10:48 AM, L. David Baron <dbaron@dbaron.org> wrote:
> > On Monday 2016-04-18 14:43 -0700, Tab Atkins Jr. wrote:
> >> I'm not aware of any plans to "switch currentcolor to a computed value
> >> for some cases" - can you elaborate?
> >
> > We've agreed to switch currentcolor to being a computed value.  We
> > errata'd css-color-3 to do that:
> > https://www.w3.org/Style/2011/REC-css3-color-20110607-errata.html#s.4.5
> > and made it such in css-color-4:
> > https://drafts.csswg.org/css-color-4/#currentcolor-color
> 
> Ah, Xidorn's wording confused me!  In particular, if currentcolor is
> turned into an RGBA at computed-value time, then there's never a
> problem at all and animations work exactly like animating between px
> and em does; the entire issue is that we've specced it to not become
> RGBA until used-value time, which instead puts us in a "px vs %"
> situation, and we need a calc() equivalent for colors to represent the
> intermediate animated value.
> 
> (I think you and he use the term "computed value" to mean something
> different than I do - I'd call "1em" a "computed value", because it's
> absolutized at computed-value time, while "width: 10%" is a "used
> value".)

I think I'm using the phrase "computed value" in its CSS meaning
("thing that is a CSS computed value"), whereas you're using it in
its English meaning to mean "thing that is computed as part of the
process of making a CSS computed value".

I think your way is confusing. :-)

> If we were completely consistent, both would act as
> -webkit-text-fill-color does here.  If we added a blend() function and
> used it for interpolation, the reverse would happen in practice; both
> would act like border-color does here.  Decide which one you want, and
> we can make sure it happens.

I'm guessing it is probably better (and generally more compatible)
to use blend(), although there are many cases I haven't tested.

(The thing that is known to cause compatibility problems is
triggering transitions for -webkit-text-fill-color when the value
changes from currentColor to currentColor (which are potentially
different values because color changes).  Treating currentColor as a
computed value consistently, including for animations, fixes this.)

> > The spec currently requires (4), but we're hoping in the long term
> > to make it something more like but slightly better than (3), where
> > the animation treats currentcolor as a computed value so it doesn't
> > interpolate changes from currentcolor to currentcolor when color
> > changes (which is the problem that caused bug 1260543, because that
> > created a -webkit-text-fill-color value that inherited to a
> > descendant that specified color, and then overrode that color) but
> > that it does animate between currentcolor and real color values.
> 
> This is solved by a blend() function, as I outlined above;
> "currentcolor" to "currentcolor" is no change and so no transition
> occurs, but "currentcolor" to "red" is animated with
> "blend(currentcolor, red X%)" (even if the currentcolor was, at the
> time, red).

I think this makes getting blend() stable a priority, since I think
having blend() may block getting the currentcolor change fully
implemented.

-David

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)