Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
andruud opened this issue Mar 20, 2019 · 6 comments
Closed

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

andruud opened this issue Mar 20, 2019 · 6 comments
Labels
css-animations-1 Current Work

Comments

@andruud
Copy link
Member

andruud commented Mar 20, 2019

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.

@emilio
Copy link
Collaborator

emilio commented Mar 20, 2019

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
Copy link
Member Author

andruud commented Mar 21, 2019

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

@andruud
Copy link
Member Author

andruud commented Mar 21, 2019

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
Copy link
Collaborator

SelenIT commented Mar 21, 2019

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
Copy link
Contributor

birtles commented Mar 22, 2019

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.

@birtles birtles added the css-animations-1 Current Work label Mar 22, 2019
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Apr 16, 2020
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
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Apr 16, 2020
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}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Apr 16, 2020
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}
pull bot pushed a commit to FreddyZeng/chromium that referenced this issue Apr 16, 2020
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}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Apr 25, 2020
…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
xeonchen pushed a commit to xeonchen/gecko that referenced this issue Apr 25, 2020
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this issue Apr 25, 2020
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this issue Apr 25, 2020
…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
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this issue Apr 25, 2020
…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
Copy link
Member Author

andruud commented Aug 6, 2020

Closing as Duplicate of #5125.

@andruud andruud closed this as completed Aug 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
css-animations-1 Current Work
Projects
None yet
Development

No branches or pull requests

4 participants