[css-animations-1] Font-relative units in keyframes #3751

andruud · 2019-03-20T14:15:04Z

What does em resolve against in the following animation?

@keyframes anim1 {
    from { font-size: 10px; width: 10em; }
    to   { font-size: 20px; width: 20em; }
}

In Chrome, anim1 produces an animation for width in em-space, where em is resolved against the animated font-size for each frame.

In FF, anim1 produces an animation for width from 160px to 320px, i.e. the font-size of the keyframe is ignored.

The text was updated successfully, but these errors were encountered:

emilio · 2019-03-20T15:14:50Z

cc @birtles

I think off-hand I'd consider this a Firefox bug. But note that Blink has issues in here as well (i.e., I think the third element in this test-case should grow):

<!doctype html>
<style>
@keyframes anim1 {
  from { width: 10em; font-size: 10px; }
  to   { width: 30em; font-size: 50px; }
}

@keyframes anim2 {
  from { font-size: 10px; width: 10em; }
  to   { font-size: 50px; width: 30em; }
}

@keyframes anim3 {
  from { font-size: 10px; }
  to   { font-size: 50px; }
}

div {
  height: 60px;
  background: purple;
  animation: anim1 10s linear infinite;
  margin: 5px 0;
}

div + div {
  animation-name: anim2;
}
div + div + div {
  width: 30em;
  animation-name: anim3;
}
</style>
<div></div>
<div></div>
<div></div>

andruud · 2019-03-21T08:25:11Z

Yeah, that's a known related issue in Blink.

andruud · 2019-03-21T10:04:32Z

Hmm. 🤔

§ 3. Animations [css-animations-1]:

CSS Animations affect computed property values. This effect happens by adding a specified value to the CSS cascade ([CSS3CASCADE]) (at the level for CSS Animations) that will produce the correct computed value for the current state of the animation.

But then also:

§ 3. Combining Values: Interpolation, Addition, and Accumulation [css-values-4]

These operations are only defined on computed values. (As a result, it is not necessary to define, for example, how to add a value of 15pt with 5em since such values will be resolved to their canonical unit before being passed to any of the above procedures.)

So ... should the interpolation happen in em space, or not?

SelenIT · 2019-03-21T14:55:32Z

The newest definition of the width property that I could find (in [css-sizing-3]) says that its animation type is "by computed value type", and computed value is "as specified, with <length-percentage> values computed". The [css-animations] spec seems to have no exact rules of length interpolation, instead it has an issue linking to the [css-transitions] rules as an example. These rules imply that interpolation happens between the start and end values only, i.e. Firefox's behavior seems to be correct according to them (though it might be counter-intuitive).

Interestingly, the MDN page for the width property currently reports its animation type as "a length, percentage or calc();", apparently implying that calc() is a separate animation type, so interpolations between 10em and 20em and between calc(10em) and calc(20em) would probably happen in different spaces. But I haven't found any justification for such distinction in neither [css-values-4] nor animations nor transitions spec.

With all that said, I wouldn't consider either behavior a bug until the [css-animations] spec resolves its issue about the interpolation rules between keyframes.

birtles · 2019-03-22T01:07:43Z

So this is basically a dupe of #66 (which, if you follow far enough, will take you to this mail from dbaron)

I wrote a test case with a few variations on the test case from the first comment: https://codepen.io/birtles/pen/drQQaJ.

Blink seems to mostly do G-β but has trouble with overlapping keyframes and, as Emilio points out, reflecting the animated font-size on static declarations.

Edge doesn't seem to recognize animation-timing-function on keyframes when there are overlapping keyframes. I didn't test Emilio's example on Edge.

I thought we fixed some of these issues in Firefox when we switched to Servo, but I guess not. I believe we might have deferred the ordering dependency introduced by font-size until we implement animation of custom properties since they introduce further ordering dependencies between properties.

So I think we already have a resolution to do G-β, it just needs to be implemented in Firefox, tested (the WPT for this spec need rewriting first) and specced. Unfortunately this behavior does mean that some animations can no longer effectively be run on the compositor.

This is the "Keyframe Animation Inconsistency" described in the initial StyleCascade design doc [1] (see Appendix). This was fixed at some point during the StyleCascade work, probably when interpolations started using the same StyleCascade instance as the main declarations. The test only asserts equality between the standard and custom property cases, while ignoring absolute values, as browser disagree wildly on what that value should be at the moment [2]. [1] https://docs.google.com/document/d/1HrmPmcQBTUMouqQQG3Kww43I5aFW9-Q9tr-DEKZk09I [2] w3c/csswg-drafts#3751 Change-Id: I1447aea439fe60cce1d280b0310a0983e71155b1

This is the "Keyframe Animation Inconsistency" described in the initial StyleCascade design doc [1] (see Appendix). This was fixed at some point during the StyleCascade work, probably when interpolations started using the same StyleCascade instance as the main declarations. The test only asserts equality between the standard and custom property cases, while ignoring absolute values, as browser disagree wildly on what that value should be at the moment [2]. [1] https://docs.google.com/document/d/1HrmPmcQBTUMouqQQG3Kww43I5aFW9-Q9tr-DEKZk09I [2] w3c/csswg-drafts#3751 Change-Id: I1447aea439fe60cce1d280b0310a0983e71155b1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2150432 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/master@{#759618}

…ize/width/<length> animation, a=testonly Automatic update from web-platform-tests Add WPT coverage for simultaneous font-size/width/<length> animation This is the "Keyframe Animation Inconsistency" described in the initial StyleCascade design doc [1] (see Appendix). This was fixed at some point during the StyleCascade work, probably when interpolations started using the same StyleCascade instance as the main declarations. The test only asserts equality between the standard and custom property cases, while ignoring absolute values, as browser disagree wildly on what that value should be at the moment [2]. [1] https://docs.google.com/document/d/1HrmPmcQBTUMouqQQG3Kww43I5aFW9-Q9tr-DEKZk09I [2] w3c/csswg-drafts#3751 Change-Id: I1447aea439fe60cce1d280b0310a0983e71155b1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2150432 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/master@{#759618} -- wpt-commits: fc468874fa836b89cff342e9e35dc8c0379c4beb wpt-pr: 22991

…ize/width/<length> animation, a=testonly Automatic update from web-platform-tests Add WPT coverage for simultaneous font-size/width/<length> animation This is the "Keyframe Animation Inconsistency" described in the initial StyleCascade design doc [1] (see Appendix). This was fixed at some point during the StyleCascade work, probably when interpolations started using the same StyleCascade instance as the main declarations. The test only asserts equality between the standard and custom property cases, while ignoring absolute values, as browser disagree wildly on what that value should be at the moment [2]. [1] https://docs.google.com/document/d/1HrmPmcQBTUMouqQQG3Kww43I5aFW9-Q9tr-DEKZk09I [2] w3c/csswg-drafts#3751 Change-Id: I1447aea439fe60cce1d280b0310a0983e71155b1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2150432 Reviewed-by: Rune Lillesveen <futharkchromium.org> Commit-Queue: Anders Hartvoll Ruud <andruudchromium.org> Cr-Commit-Position: refs/heads/master{#759618} -- wpt-commits: fc468874fa836b89cff342e9e35dc8c0379c4beb wpt-pr: 22991 UltraBlame original commit: ec4d98a812265604fd30612d4177b0a41f3542b7

andruud · 2020-08-06T10:14:01Z

Closing as Duplicate of #5125.

…ize/width/<length> animation, a=testonly Automatic update from web-platform-tests Add WPT coverage for simultaneous font-size/width/<length> animation This is the "Keyframe Animation Inconsistency" described in the initial StyleCascade design doc [1] (see Appendix). This was fixed at some point during the StyleCascade work, probably when interpolations started using the same StyleCascade instance as the main declarations. The test only asserts equality between the standard and custom property cases, while ignoring absolute values, as browser disagree wildly on what that value should be at the moment [2]. [1] https://docs.google.com/document/d/1HrmPmcQBTUMouqQQG3Kww43I5aFW9-Q9tr-DEKZk09I [2] w3c/csswg-drafts#3751 Change-Id: I1447aea439fe60cce1d280b0310a0983e71155b1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2150432 Reviewed-by: Rune Lillesveen <futhark@chromium.org> Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org> Cr-Commit-Position: refs/heads/master@{#759618} -- wpt-commits: fc468874fa836b89cff342e9e35dc8c0379c4beb wpt-pr: 22991

birtles added the css-animations-1 Current Work label Mar 22, 2019

chromium-wpt-export-bot mentioned this issue Apr 16, 2020

Add WPT coverage for simultaneous font-size/width/<length> animation web-platform-tests/wpt#22991

Merged

andruud closed this as completed Aug 6, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[css-animations-1] Font-relative units in keyframes #3751

[css-animations-1] Font-relative units in keyframes #3751

andruud commented Mar 20, 2019

emilio commented Mar 20, 2019

Uh oh!

andruud commented Mar 21, 2019

Uh oh!

andruud commented Mar 21, 2019

Uh oh!

SelenIT commented Mar 21, 2019

Uh oh!

birtles commented Mar 22, 2019

Uh oh!

andruud commented Aug 6, 2020

Uh oh!

[css-animations-1] Font-relative units in keyframes #3751

[css-animations-1] Font-relative units in keyframes #3751

Comments

andruud commented Mar 20, 2019

emilio commented Mar 20, 2019

Uh oh!

andruud commented Mar 21, 2019

Uh oh!

andruud commented Mar 21, 2019

Uh oh!

SelenIT commented Mar 21, 2019

Uh oh!

birtles commented Mar 22, 2019

Uh oh!

andruud commented Aug 6, 2020

Uh oh!