Re: [csswg-drafts] [css-view-transitions-2] Elements with content-visibility in new Document (#10773)

The CSS Working Group just discussed `[css-view-transitions-2] Elements with content-visibility in new Document`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> noamr: issue with how cross-document VTs, the order that things are discovered for an incoming VT<br>
&lt;TabAtkins> noamr: We check for the names, and only after check if the element is visible (based on content-visibility:auto)<br>
&lt;TabAtkins> vmpstr: for initial c-v:auto determination, it happens during "update the rendering" in html<br>
&lt;TabAtkins> vmpstr: if we ahve an incoming VT, we need to determine which elements are matched to the old doc *prior* to running "update the rendering"<br>
&lt;TabAtkins> vmpstr: so we have an issue, all the c-v:auto things aren't matched even if they're in the viewport, because we haven't determined their visibiility yet<br>
&lt;TabAtkins> vmpstr: so proposal is, if we ahve an incoming VT, we run the c-v:auto determination first<br>
&lt;TabAtkins> vmpstr: this might also apply to same-doc transitions if you've added an element to the DOM with c-v:auto<br>
&lt;Rossen6> q<br>
&lt;emilio> q+<br>
&lt;TabAtkins> vmpstr: but it's less clear that's needed, since the same-doc steps happen in a different spot. but we do want the same ability<br>
&lt;TabAtkins> emilio: are you proposing to run the determination steps again/first, or *move* them?<br>
&lt;TabAtkins> vmpstr: the initial determination has to just run before the VT matching steps<br>
&lt;TabAtkins> vmpstr: so i'm proposing that we do it *again* if there's an incoming VT<br>
&lt;Rossen6> ack emilio<br>
&lt;TabAtkins> vmpstr: doesn't duplicate work because the second time it's not the initial determination, it's a subsequent<br>
&lt;TabAtkins> emilio: I thought VT operations already happened after this, maybe I was wrong<br>
&lt;TabAtkins> vmpstr: for the cross-doc case, it happens before<br>
&lt;TabAtkins> vmpstr: it needs to happen before frames are drawn in the new doc<br>
&lt;TabAtkins> vmpstr: so "udpate the rendering" hasn't run yet<br>
&lt;TabAtkins> emilio: okay, so cross-doc VT runs the c-v:auto determination explictly, outside the rendering loop<br>
&lt;TabAtkins> vmpstr: yeah<br>
&lt;TabAtkins> emilio: it's a little sad, might expect intersection observers to also work...<br>
&lt;TabAtkins> emilio: maybe it's better to run the whole rendering loop but not point, that seems tricky to define tho<br>
&lt;TabAtkins> emilio: maybe that's fine, but wondering if we've consdiered larger changes like that<br>
&lt;TabAtkins> vmpstr: we haven't<br>
&lt;TabAtkins> vmpstr: the c-v case was a bug report<br>
&lt;TabAtkins> vmpstr: haven't seen other cases reported yet<br>
&lt;TabAtkins> vmpstr: don't thi8nk we want to run the rAF handlers without them producing paint<br>
&lt;TabAtkins> emilio: maybe not, but also it might not be too bad?<br>
&lt;TabAtkins> emilio: but if you did a c-v:auto-like thing with IO you might want that to run<br>
&lt;bramus> q+<br>
&lt;TabAtkins> emilio: seems a bit whack-a-mole if we need to keep adding things for the VT step<br>
&lt;TabAtkins> vmpstr: if there's script involved, yeah, that won't trigger. but c-v is a CSS thing, so as long as things are declarative they should all "work"<br>
&lt;TabAtkins> vmpstr: but script is tricky<br>
&lt;smfr> +1 to emilio<br>
&lt;TabAtkins> emilio: i think my pref would be to try running one frame without painting, that might work, but that's a bit awkward. dont' want to block if you're certain on this approach, just feels a bit special-casey for my taste<br>
&lt;TabAtkins> bramus: wanted to underline the c-v part affects whether the element is captured or not, authors have reported that<br>
&lt;Rossen6> ack bramus<br>
&lt;TabAtkins> bramus: maybe we can resolve on just the c-v part and then experiment with the frame render?<br>
&lt;emilio> q+<br>
&lt;TabAtkins> bramus: some people are blocked on this right now, they can't add the c-v perf improvement to their website due to VTs<br>
&lt;Rossen6> ack emilio<br>
&lt;TabAtkins> emilio: there are two approaches, right? a third is to make c-v:auto not behave as hidden for VT. i think scrollIntoView() already acts like you're visible<br>
&lt;TabAtkins> emilio: so it's not unheard of<br>
&lt;TabAtkins> vmpstr: with find-in-page there's no difference, but this would defeat the style optimation for c-v:auto on navigations that have an incoming VT<br>
&lt;TabAtkins> vmpstr: there's no user action besides the navigation, and we need to run style on the whole document to find names then<br>
&lt;TabAtkins> vmpstr: we've previously decided that in same-doc, if a c-v auto is off-screen then a sub-element won't be available for VT<br>
&lt;TabAtkins> emilio: right, point is that you don't have to paint it, you just check for names<br>
&lt;TabAtkins> Rossen6: out of time on the call, don't feel like we're ready to resolve.<br>
&lt;TabAtkins> Rossen6: continue discussion in the issue<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10773#issuecomment-2654472392 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 12 February 2025 18:01:21 UTC