- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Thu, 11 Apr 2024 08:44:54 +0000
- To: public-css-archive@w3.org
^ we only clip the root snapshot to the snapshot containing block. Non-root elements are captured in entirety (modulo hardware constraints). If we were to clip element snapshots to the snapshot containing block, they'd be completely empty for offscreen elements. IIUC the examples @jakearchibald is mentioning don't want that behaviour, since the animation can bring the content onscreen we need to capture the offscreen pixels. > I think that example is a misunderstanding of how to use view transitions, in the same way * { will-change: transform } is a misunderstanding. Authors should only be putting view transition names on things that need to transition. That's fair but `will-change` comes with a huge disclaimer about its rendering characteristics. Since the property is explicitly about adding rendering cost for animation smoothness, authors have to realize what they're doing when they use this property. `view-transition-name`'s primary purpose is element matching. The offscreen rendering is pretty subtle so I doubt authors will think about it. In fact most will probably assume what you said above, "same as CSS animations ...". Put an animation on everything you need and the browser will deal with optimizing offscreen stuff. Picking a default to always capture for this new property is a bit like picking `transform` as the default value for `will-change` from a perf standpoint. I realize it's more nuanced since `will-change` is purely perf, while there is visual impact based on the default we use here. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8282#issuecomment-2049216260 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 11 April 2024 08:44:55 UTC