-
Notifications
You must be signed in to change notification settings - Fork 645
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-2] Consider not generating a CSSAnimation with null timeline #7364
Comments
Thanks Boris for this great summary. I was thinking over this problem again this morning and I think I overlooked something. I'm afraid I'm unfamiliar with how scroll animations are expected to be used, but do we expect authors to update the computed style of If so, I think option 2 would be preferred. Presumably, in that case, when In order to be consistent, when setting the timeline to That would suggest that having a non-null timeline is not a prerequisite for generating a |
Thanks, Brian. Option 2 also makes sense to me. It seems Chrome Canary doesn't preserve the progress when changing the timeline from scroll-timeline to none. However, [web-animations-2] is still under development, so just want to make sure which option is what we expect for the future. |
The step 11 of setting-the-timeline in web-animations-2:
So this is a general case when changing the timeline from a scroll-timeline to any other one (including null timeline). If this is the use case that the developers want, option 2 may be what we need. |
Close this per the previous comment. We should rely on the procedure to set the timeline of an animation. So if the behavior is inconsistent, we should update the procedure. |
I'd like to make this proposal for the following cases:
animation-timeline: none
initiallyanimation-timeline: unknown-timeline
initiallyanimation-timeline
from a valid timeline tonone
animation-timeline
from a valid timeline to an unknown-timelineanimation-timeline
is defined in [css-animations-2], and the timeline name is defined in [scroll-animations]. However, it's unclear to us for null timeline case.There is a wpt for case 1 and case 2. In this test case, we expect to hold the current time at zero. This means we still generate the CSS animation with null timeline.
However, there is another wpt for case 3 and case 4. In this test case, we expect to discard the CSS animations (or say, the CSS animations are cancelled or not in effect).
This may confuse people because all the cases should have the same behavior in general, just like what we do for
@keyframes
.That is, if there is no matching
@keyframes
rule, we don't generate aCSSAnimation
. If the@keyframes
rule later matches, we generate theCSSAnimation
then. That is defined in step 3 of the procedure to generate keyframe objects:So just want to raise this spec issue for discussion. And based on the comment @birtles left in https://bugzilla.mozilla.org/show_bug.cgi?id=1774060#c4, for these 4 cases:
Option 1:
animation-timeline: none
initially -> No CSSAnimation is generatedanimation-timeline: unknown-timeline
initially -> No CSSAnimation is generatedanimation-timeline
from a valid timeline tonone
-> The existing CSSAnimation is cancelled.animation-timeline
from a valid timeline to an unknown-timeline -> The existing CSSAnimation is cancelled.Option 2:
The alternative is to always generate a
CSSAnimation
and set the timeline to null whenanimation-timeline
isnone
or some unknown-timeline and follow the procedure for setting a timeline to null defined in [web-animations-2].Mozilla prefers the option 1 for now, and so I'd like to update this wpt based on the option 1.
Do we have any concerns for this?
cc @kevers-google, @andruud, @hiikezoe
The text was updated successfully, but these errors were encountered: