[web-animation-2] Resolution of fill=auto for progress-based timelines #6673
Conversation
| > * the <a>animation effect</a> to which the fill mode is being | ||
| > is applied is not a <a>keyframe effect</a>, | ||
| > * the <a>animation effect</a> is associated with a | ||
| > [=progress-based timeline=] |
There was a problem hiding this comment.
I suspect we might want this to be as narrow as possible. E.g. if the animation active active phase does not touch the end of the timeline it probably shouldn't fill. How about we add something like "and the start delay + active duration = 100%"?
Also, does this need to be fill: both? The start time is inclusive so we only need to extend the end to make it end-inclusive. The complication is of course that we have to flip the fill when the animation direction is "backwards" but this seems not too complicated.
There was a problem hiding this comment.
I think the first condition is in agreement with the updated definition for 'auto' here: https://drafts.csswg.org/web-animations-2/#the-fillmode-enumeration but perhaps we could phrase it to be more generic such that each type of animation effect defines what "auto" means to it? e.g. introduce a term for that? intrinsic fill mode, default fill mode or something?
For the second condition I'm not sure. In general I prefer a wider definition because it feels less magical and more composable if there are fewer rules to consider. Furthermore, "fill: both" would mean we don't need to worry about the reversing case. However, I don't have a good sense for the implications of extending the fill mode to scroll-linked content. Is there any example content (real or artificial) that highlights the difference?
There was a problem hiding this comment.
I agree it would be nice to have a simple definition here. It could be something like if the animation effect is associated with a progress-based timeline and the specified effect duration is 'auto', then the intrinsic fill mode is 'both'. This would handle simple cases like:
// simple parallax
element.animate({transform: ['translateY(100px)']}, {timeline: new ScrollTimeline()});The reason not to always use fill-mode: both is that it would be surprising in cases where the developer specifies an animation that does not fill the scroll range:
-
when the developer specifies a duration and end delay, e.g.
element.animate({transform: ['translateY(-50px)', 'none']}, {duration: 1000, endDelay: 1000, timeline: scrollTimeline}), we follow the procedure to convert to progress and have a computed duration of 50%. The developer would expect the animation not to be in effect during the end delay period. -
when we allow specifying percentage durations (e.g. as CSSNumericValues or percentage strings), the developer may specify one or more animations which are meant to follow each other, e.g.
element.animate({transform: ['translateY(-50px)', 'none']}, {duration: CSS.percent(10), timeline: scrollTimeline}); element.animate({transform: ['none', 'translateY(50px)']}, {duration: CSS.percent(10), startDelay: CSS.percent(90), timeline: scrollTimeline})
-
when multiple effects are used with a SequenceEffect on a ScrollTimeline, the effects should split the duration of the timeline duration and we'd only expect the last effect to
fill: forwardsto include the end position.
Of course the developer can always override the fill mode in some of those scenarios, I'd just like to get it right in most cases if we can.
There was a problem hiding this comment.
Planning to put this PR on the back burner pending resolution of #6508. If the problem is limited to precisely the timeline boundaries, then perhaps best to resolve there. The fill resolution will get cumbersome if it needs to take into account start and end delays and also offsets that are not aligned at 0 and 100%.
|
Abandoning this PR due to https://github.com/w3c/csswg-drafts/pull//6702. |
[web-animation-2] Resolution of fill=auto for progress-based timelines
Update the rules for resolving a fill mode of 'auto' in timeline calculations based on discussion in issue #5223