- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Apr 2024 14:23:59 +0000
- To: public-css-archive@w3.org
> If that design choice is taken away from me, the feature is useless. This feature is about design choice. That's a fair point Jake. There is no doubt that we need an API here because it's about the UI the author is trying to design which the browser can't infer. So a heuristic only solution is not feasible. That said, we still need to decide what should be the reasonable default behaviour. I was assuming that an animation where both the start and end states (or just the one state for entry/exit transitions) of the DOM element are offscreen should be skipped, because the user will never see that animation. But I'm likely missing a case since you mentioned: "sometimes I'm happy with an element animating from outside the viewport to outside the viewport". Do you have an example in mind? Since the browser can't know if the end state will be onscreen, we have 2 choices for the default: 1. Conservatively always capture, which is the current spec. The pro is that it's likely to be more visually correct. The con is its suboptimal because we're spending resources for offscreen animations. 2. Ignore elements in the old DOM if they are far offscreen which is inverse of above, trading visual correctness to err on better perf. My inkling is that authors are more likely to notice the visual glitch and fix it by using the property proposed here than to realize the performance footgun of offscreen animations. What would be your preference for the default behaviour? -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8282#issuecomment-2047698168 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 10 April 2024 14:24:00 UTC