You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We recently discussed the issue about inactive timelines — #9256
Today, a new ticket was created in Firefox’ bugzilla about one related topic: bugzilla.mozilla.org/show_bug.cgi?id=2043712 — “view-timeline on a non-scrolling scroller should produce the animation effect”.
If the source or subject of a ViewTimeline is an element whose principal box does not exist, or if its nearest ancestor scroll container has no scrollable overflow (or if there is no such ancestor, e.g. in print media), then the ViewTimeline is inactive.
(emphasis mine)
The issue: this seems to be not what Chrome and Safari currently do.
This is also something that does not make much sense from a practical perspective. At least from mine, as an authors: I heavily relied on this practical aspect of view timelines that currently works in Chrome and Safari in my articles: https://kizu.dev/position-driven-styles/ and https://kizu.dev/shrinkwrap-solution/, and especially the examples in the first article can demonstrate what the main issue with the behaviour-as-specced is. Here is a screencast of its current behavior in Firefox:
Screen.Recording.2026-05-29.at.22.21.56.mov
On this video you can see the first example from my “Position-Driven Styles” article, where the inner scroll container that wraps elements with the view timelines starts without having a scrollable overflow, but when resizing the container, it gains it.
The screencast shows how when there is no scrollable overflow, the animations on the elements are inactive, but when the scrollable overflow appears, all animations suddenly become active.
While examples in my articles can be considered extreme, I would argue that this behavior will be confusing for authors, and potentially harmful for users: any elements that rely on view timelines could arbitrarily jump on the page if something causes the page to gain/lose overflow.
Simple example: some <details> tag that is initially collapsed inside a scroll container, making it not have a scrollable overflow, and when you expand such container, some element inside without changing its position will get the animation applied via a jump.
Here is a ~minimal example of something more practical that could happen: https://codepen.io/kizu/pen/myOpBVM (note that this one starts at a 0% progress due to its circumstances, but with a different range/setup it could start at a diff %).
In Chrome/Safari, the style of this element is not affected by the details being expanded or not. And when you expand details and scroll, you see the animation in action. In Firefox, the animation does not have any effect at all until you open details, resulting in a color jump.
My proposal would be to remove the “if its nearest ancestor scroll container has no scrollable overflow” part at least for view timelines — for any view the element’s position can correspond to a certain position in the view timeline, there should be no reason to make these inactive/not apply the styles.
We recently discussed the issue about inactive timelines — #9256
Today, a new ticket was created in Firefox’ bugzilla about one related topic: bugzilla.mozilla.org/show_bug.cgi?id=2043712 — “view-timeline on a non-scrolling scroller should produce the animation effect”.
The current specs on ViewTimeline say this:
(emphasis mine)
The issue: this seems to be not what Chrome and Safari currently do.
This is also something that does not make much sense from a practical perspective. At least from mine, as an authors: I heavily relied on this practical aspect of view timelines that currently works in Chrome and Safari in my articles: https://kizu.dev/position-driven-styles/ and https://kizu.dev/shrinkwrap-solution/, and especially the examples in the first article can demonstrate what the main issue with the behaviour-as-specced is. Here is a screencast of its current behavior in Firefox:
Screen.Recording.2026-05-29.at.22.21.56.mov
On this video you can see the first example from my “Position-Driven Styles” article, where the inner scroll container that wraps elements with the view timelines starts without having a scrollable overflow, but when resizing the container, it gains it.
The screencast shows how when there is no scrollable overflow, the animations on the elements are inactive, but when the scrollable overflow appears, all animations suddenly become active.
While examples in my articles can be considered extreme, I would argue that this behavior will be confusing for authors, and potentially harmful for users: any elements that rely on view timelines could arbitrarily jump on the page if something causes the page to gain/lose overflow.
Simple example: some
<details>tag that is initially collapsed inside a scroll container, making it not have a scrollable overflow, and when you expand such container, some element inside without changing its position will get the animation applied via a jump.Here is a ~minimal example of something more practical that could happen: https://codepen.io/kizu/pen/myOpBVM (note that this one starts at a 0% progress due to its circumstances, but with a different range/setup it could start at a diff %).
In Chrome/Safari, the style of this element is not affected by the details being expanded or not. And when you expand details and scroll, you see the animation in action. In Firefox, the animation does not have any effect at all until you open details, resulting in a color jump.
My proposal would be to remove the “if its nearest ancestor scroll container has no scrollable overflow” part at least for view timelines — for any view the element’s position can correspond to a certain position in the view timeline, there should be no reason to make these inactive/not apply the styles.