- From: Khushal Sagar via GitHub <sysbot+gh@w3.org>
- Date: Tue, 19 Nov 2024 22:25:33 +0000
- To: public-css-archive@w3.org
> All of this happens before the content-visibility loop. That's what's causing this problem and why it particularly affects only new DOM capture. For old DOM capture, looking for names happens after this step. > We could also assume content-visibility: auto elements are relevant for the purposes of view-transition names. We do that for find in page and scroll-into-view already, correct? The problem with this is that it makes `content-visibility` somewhat irrelevant as an optimization if you add VT to your page. One of its goals was to make FCP faster by avoiding style/layout of content which is far offscreen. If we force it to be relevant on the first frame then that gain is lost. The issue where we resolved on this behaviour also concluded that there's no user benefit to forcing this content to be relevant. There's no use-case where far offscreen content needs to participate in the transition. We just don't know the position of these nodes until the first layout to determine whether they should be locked or not. That's why the ideal fix would be to make that determination before we look for names in the new DOM. Tangential question, "scroll-into-view" reminded me of "scroll-to-text". I suppose it's like having "find-in-page" automatically run on page load where we're forcing nodes to become relevant. I'd still say there's a user benefit/need to do that here but not for VT. -- GitHub Notification of comment by khushalsagar Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10773#issuecomment-2486876892 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 November 2024 22:25:34 UTC