[css-animations] computation of values in keyframes (was Re: Possible spec bug?)

So this was raised in today's meeting agenda at
http://lists.w3.org/Archives/Public/www-style/2014Jul/0245.html as
"Animating shorthand properties" (though we didn't get to it in the
meeting), though it's actually not specific to shorthands:

On Sunday 2011-10-30 00:02 +0300, Lea Verou wrote:
> Check this out: http://jsfiddle.net/leaverou/jwHva/2/
> 
> If you remove border-style: solid; from the div {...} rule, the
> animation stops having a visible effect, even though both the
> interpolated values contain border-style:solid; (in the shorthand).
> This doesn't change even with animation-fill-mode: both; It happens
> in both Webkit and Mozilla, so it's probably not a browser bug.
> 
> I discussed it with David Baron on IRC and his explanation was this:
> dbaron: I think it may be because each property in the animation
> gets handled separately
> dbaron: on top of the base values
> dbaron: and with a 'none' border style the border-width doesn't do anything
> leaverou: but I defined border-style in the animation, through the shorthand
> dbaron: I doubt the spec is clear on this point, though.
> dbaron: yeah
> dbaron: my guess (haven't checked yet)
> dbaron: is that despite that, the border-width computes to zero in
> the animation
> 
> I took a look at the spec, but couldn't find anything relevant.
> I think it's very confusing behavior and potentially a spec bug, so
> thought I'd let you guys know.

The issue here is really, I think, about how the base values in
keyframes are computed, and has rather little to do with shorthands.

The animations spec requires coming up with a computed value for
each property that the animation is animating.  (It needs to decide
which those are, since the animation overrides those properties but
does not override other properties.)  This is currently the set of
properties specified in keyframes (although implementations
implement it as the set of animatable properties specified in
keyframes).

A computed value for a property can depend on the computed values of
other properties on the same element (or of properties on the
parent, etc., but that's less interesting in this case).  When we
determine the computed value of a property in a keyframe, we assume
that the computed values of other properties are determined using
the other styles that apply to that element.  For example, given:
  #a { animation: a; font-size: 16px; }
  @keyframes a { 0% { text-indent: 2em } }
the 0% keyframe is interpreted as though it has a text-indent of 32px.

The first open question is whether other properties in the same
keyframe can change this.  In other words, given:
  #a { animation: a; font-size: 16px; }
  @keyframes a { 0% { font-size: 32px; text-indent: 2em } }
does the font-size: 32px inside the keyframe change the value of
text-indent (and make it 64px rather than 32px)?

(When considering this question, remember that the underlying model
is that the animations for each property are built separately, since
if a property is missing from a keyframe, the implementation acts as
though that keyframe were not present when animating that property.)

The second open question (perhaps less relevant if we're going to
stick with the plan to change to supporting all properties in
keyframes rather than just animatable ones, even though I don't
think anyone has implemented that yet) is whether, assuming the
answer to the previous question is yes, whether this still holds
true for non-animatable properties, such as in:
  #a { animation: a; }
  @keyframes a { 0% { border-left-style: solid; border-left-width: 10px } }
where the computed value of border-left-width is 0px if
border-left-style is its initial value (none), but 10px if the
border-left-style in the keyframe is honored.  So this second
question is whether the non-animatable property is used when
computing the base value.  (In the above example, an answer of no
yields 0px, and an answer of yes yields 10px.)  (This is the issue
in Lea's testcase.)

I put a testcase testing these two issues (although in the reverse
order, and with a variant of the second) at:
http://lists.w3.org/Archives/Public/www-archive/2014Jul/att-0030/animations.html

Firefox answers yes to the first question (b = 64px) and no to the
second (a = 0px).  A rather out-of-date Chromium that I have around
matches.

I don't believe the spec is clear on what happens, but it should be.

I don't have particularly strong opinions on what should happen, but
we might be constrained by compatibility.  (We also might be
constrained by compatibility in terms of making all properties apply
in keyframes, though.)


Tab proposed in this thread back in 2011 that the 0% and 100%
keyframes be "fully applied", although I'm not quite sure what it
means and I don't think I like the sound of it.

-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)