- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Apr 2023 16:36:43 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] Enforce ::view-transition to be fixed position`, and agreed to the following: * `RESOLVED: Define "snapshot CB" as the current snapshot root rect, give it ICB behaviors so it captures all elements (preventing them from going higher)` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> (vlad and khush are beign eaten by the AI)<br> <TabAtkins> vmpstr: We currently have a ::view-transition pseudo, the root of the whole VT pseudo-tree.<br> <TabAtkins> vmpstr: It has fixpos, and uses snapshot root as the contining block<br> <TabAtkins> vmpstr: We'd like to make fixpos unchangeable, via UA !important<br> <TabAtkins> vmpstr: Because we want the root pseudo to be a containing block to all other pseudos<br> <emilio> q+<br> <TabAtkins> vmpstr: If we don't have that, and author can change it, we'd have to figure out what the VT pseudos *should* use. Haven't found any use-case for it, so propose to enforce it<br> <astearns> ack emeyer<br> <astearns> ack emilio<br> <TabAtkins> emilio: I think it's fine, but do you also want to ensure you're a containing block for other fixpos children?<br> <TabAtkins> vmpstr: Does fixpos not contain fixpos?<br> <TabAtkins> TabAtkins: No<br> <TabAtkins> vmpstr: Okay then we'd also like it to be a fixpos containing block for its descendants.<br> <TabAtkins> emilio: Okay can do that in a few ways, or with magic. Like a no-op filter.<br> <TabAtkins> emeyer: Maybe just say it happens.<br> <TabAtkins> s/emeyer/emilio/<br> <TabAtkins> vmpstr: I'd say UA magic is fine, the structure of the tree is also unchangeable<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: Would it make sense, instead, to define that the VT tree is contained by the snapshot root?<br> <TabAtkins> fantasai: In the same way the rest of the doc is contained by the ICB?<br> <TabAtkins> fantasai: LIke, you can't position anything based on higher than the ICB, we can say the same for the snapshot root for VT pseudos<br> <TabAtkins> fantasai: So if you change the position of VT, it'll still be laid out in the snapshot root, and children will still use the snapshot root as well, as normal<br> <TabAtkins> fantasai: So it basically lives in its own layout tree<br> <TabAtkins> vmpstr: I think.... that's fine. We basically just want to avoid going to the ICB in some cases<br> <TabAtkins> vmpstr: But as long as the CB chain stops at the snapshot root, that's fine<br> <TabAtkins> fantasai: Taht's my suggestion then, I might call it the "snapshot containing block" and define it similarly to ICB (capturing abspos, fixpos, etc)<br> <TabAtkins> astearns: Then we're not saying anything particular about the position value for the top VT pseudo?<br> <TabAtkins> fantasai: Right<br> <TabAtkins> fantasai: If you position:static, it'll be laid out as a block inside the snapshot CB<br> <TabAtkins> astearns: So proposed res is we define "snapshot containing block" for the VT pseudo-els, to get the effect we're looking for in this issue.<br> <TabAtkins> vmpstr: Defining it to be the snapshot root<br> <TabAtkins> fantasai: Yeah, rename "snapshot root" to snapshot CB and clarify it behaves as the ICB.<br> <TabAtkins> +<br> <TabAtkins> +1<br> <TabAtkins> astearns: Objections?<br> <TabAtkins> khush: Right now spec defines snapshot root to be "the rect that the viewport would be if all retractable UI is hidden"<br> <emeyer> TabAtkins: Containing block is already a rectangle<br> <emeyer> …You can literally say this is the CB<br> <TabAtkins> khush: So when we snapshot the root, we'll capture that rect as the snapshot CB<br> <TabAtkins> RESOLVED: Define "snapshot CB" as the current snapshot root rect, give it ICB behaviors so it captures all elements (preventing them from going higher)<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8505#issuecomment-1505587046 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 12 April 2023 16:36:44 UTC