- From: Jake Archibald via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 Nov 2022 12:26:55 +0000
- To: public-css-archive@w3.org
IMO, when you use `content-visibility`, you opt-in to the feature controlling the render-or-not of particular elements, so I don't think it's an issue that these elements aren't seen by view transitions. Triggering a potentially large layout in the middle of a page switch is definitely a bad thing. I'm still kinda surprised that `content-visibility` de-opts when querying particular layout info. I don't think it should do that, but I guess that's an issue for somewhere else. We talked about another feature elsewhere https://github.com/WICG/view-transitions/issues/84, that changed the behaviour of elements outside the viewport. If you opt-in to treating outside-viewport elements as "not rendered", then you avoid the heuristic behaviour of `content-visibility`. Thinking it through, I still think we have the right default - transition things from their original position. That works well for most use-cases. It doesn't work well for cases like a header transition. If the header can be scrolled away 1000s of pixels, having it transition back to the top is a bad transition. You can work around this with JS pretty easily by tagging the header dynamically if it's in the viewport, but a high-level way of doing that seems reasonable, but I don't think we need it for MVP. If a grid of items is transitioning in a way that makes them shorter, that may result in additional rows entering the viewport. In this case you really want them to animate from their original positions, even though they were outside the viewport. -- GitHub Notification of comment by jakearchibald Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7874#issuecomment-1307131406 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 8 November 2022 12:26:56 UTC