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


On Jul 16, 2014, at 2:08 PM, L. David Baron <dbaron@dbaron.org> wrote:

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

I believe you're right; but I think the spec should explain - if only
for authors' sake - how shorthands are animated, what it means to 
define shorthand values at 0% and 100% but tweak a couple of its
longhands at 30% and 50% etc. 

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

Maybe I'm not quite understanding your question but I think authors
would expect the result to be the same as applying { font-size: 32px; text-indent: 2em } 
to that element outside of an @keyframes rule. So, in this case, 64px?

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

Your parenthesized comment is definitely something I intend to clarify
here. It is also confusing to many - and me - that non-animatable 
properties get ignored. Many authors expect those to apply for the duration 
of that keyframe, which seems reasonable. If the result is unattractive or 
discontinuous, why not leave it up to them?

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

As pointed earlier, I think it is confusing for a declaration block to do
one thing when inside @keyframes and another outside. So here I think 
border-left-width should be 10px.

Which brings up another question: what happens if the next keyframes are:

20% { border-left-width: 25px; }
30% { border-left-width: 10px; }

Does nothing happens because border-left-style reset to 'none' as we 
entered the 20% keyframes? 

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

Agreed.

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

Don't know what that means either. Hope we can discuss it on next week's telcon.
> 
> -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)

Received on Thursday, 17 July 2014 23:08:10 UTC