- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Feb 2023 17:27:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] Clarify rendering constraints for elements participating in a transition`, and agreed to the following: * `RESOLVED: Remove contain:layout requirement for view-transition to work` * `RESOLVED: A non-none view-transition-name acts similar to a non-1 opacity (stacking context, grouping element, backdrop root)` <details><summary>The full IRC log of that discussion</summary> <JakeA> https://github.com/w3c/csswg-drafts/issues/8139#issuecomment-1422602510<br> <TabAtkins> JakeA: I linked to an overview<br> <TabAtkins> JakeA: trying to roll two resolutions into one, very related<br> <chris> thanks fantasai<br> <emilio> persent+<br> <TabAtkins> JakeA: when we first did an experimental impl, we required paint containment on anything that was gonna be a view transition group<br> <TabAtkins> JakeA: we improved our impl and no longer needed that<br> <TabAtkins> JakeA: We're still asking for contain:layout to make it a containing block, tho<br> <TabAtkins> JakeA: This is a bad dev exp<br> <TabAtkins> JakeA: The transition fails, dunno what's going on, have to look in devtools for it<br> <TabAtkins> JakeA: We've heard from devs they hit the smae issues<br> <TabAtkins> JakeA: So first proposed resolution is we remove the contain:layout requirement, and instead we auto-apply those containments to elements with a view-transition name<br> <florian> q+<br> <TabAtkins> JakeA: This is similar to how opacity triggers a stackign context, etc<br> <argyle> yay, remove it! JIT contain<br> <astearns> ack florian<br> <TabAtkins> florian: So when you turn things on, you're not modifying 'contain' computed value, but turning them on *as if* contain was set appropriately?<br> <TabAtkins> JakeA: Yeah, doing same as opacity<br> <TabAtkins> florian: sounds reasonable<br> <TabAtkins> florian: I think content-visibility also turns on some containment without messing with computed value<br> <miriam> `container-type` does the same<br> <dbaron> Agree that it should be consistent with content-visibility... which I think this is.<br> <TabAtkins> +1<br> <argyle> +1<br> <TabAtkins> fantasai: Are you planning to auto-apply layout containment?<br> <TabAtkins> JakeA: That's the second part of the issue<br> <TabAtkins> PROPOSED RESOLUTION: Remove contain:layout requirement from view transitions<br> <TabAtkins> TabAtkins: This is an incomplete reoslution - we're just changing it from "author must specify" to "we automatically add containment"<br> <TabAtkins> RESOLVED: Remove contain:layout requirement for view-transition to work<br> <TabAtkins> JakeA: So adding view-transition makes the element a stackign content, a backing root, etc. Same as opacity.<br> <TabAtkins> JakeA: Shoudl it also become a containing block?<br> <TabAtkins> JakeA: So what should happen to elements inside the transitioning element that use a containing block outside? We've seen examples of fixpos.<br> <fantasai> s/stackign content, a backing root, etc./generate a stacking context, be agrouping property (forces flat preserve-3d), and be a backdrop root/<br> <TabAtkins> JakeA: If the beahvior is that we capture the texture as-is (the fixpos is contained in that capture) and we do a transition where the element moves without hte fixpos moving with it<br> <TabAtkins> JakeA: it can look odd - the fixpos is now in a different relative position, but the texture hasn't been updated<br> <TabAtkins> JakeA: There's a video in the issue if my description is confusing<br> <TabAtkins> JakeA: We considered forcing a containing block to prevent that effect<br> <TabAtkins> JakeA: That requires the dev to move the fixpos out of the captured element<br> <TabAtkins> JakeA: Also considered more complex to exclude the fixpos from the capture<br> <TabAtkins> JakeA: Instead capturing it with their containing block<br> <TabAtkins> JakeA: Our conclusion is tha tforcing a CB requires the author to change their DOM, which seems bad, and we have real-world cases that hit this<br> <TabAtkins> JakeA: We also want to keep a simple rule that an element with a view-transition captures the element and its descendants. Not capturing fixposes breaks that.<br> <TabAtkins> JakeA: If we don't fix this tho, we get animations that the author clearly didn't intend<br> <TabAtkins> JakeA: The easiest fix seems to be to give the fixpos a view-transition name, so it view-transitions on its own<br> <emilio> q+<br> <astearns> ack emilio<br> <TabAtkins> JakeA: So our proposal is that view-transitions *do not* force a containing block<br> <TabAtkins> emilio: What's the plan for animating transform on the image?<br> <fantasai> summary comment is https://github.com/w3c/csswg-drafts/issues/8139#issuecomment-1422602510 btw<br> <TabAtkins> emilio: That seems like it adds complications vs creating a fixpos CB<br> <TabAtkins> JakeA: If animating a transform on the old or new view, you're moving the texture around as a group - you can see it in the video in the issue<br> <TabAtkins> emilio: You need to define the bounds that somehow encloses the abspos and fixpos, otherwise what you're animating is not... i think it introduces complications<br> <TabAtkins> JakeA: The demo I posted in the issue, I created that by having an abspos that starts outside the border of the VT element. We don't do paint containment anymore, so that's fine. You already have to calculate the size and positions from the VT elements, even i there's ink overflow (shadows, filters, or things like positioned descendants)<br> <TabAtkins> emilio: So the transform box is the element, and everything that escapes is just overflow.<br> <TabAtkins> emilio: So if you set trasnform-origin, what are those %s relative to?<br> <TabAtkins> JakeA: If you're setting trasnform-origin on the ::view-* pseudos, it's relative to the border box of that element.<br> <TabAtkins> JakeA: We allow repalced content to overflow (ink overflow).<br> <TabAtkins> emilio: Right, but ink overflow here includes abspos element that used to overflow the transitioning element<br> <TabAtkins> JakeA: That's true today, right?<br> <TabAtkins> emilio: The box relationship is different when you have fixpos inside a transform vs not<br> <khush> q+<br> <TabAtkins> emilio: So it might be weird if it takes the same trasnform origin<br> <TabAtkins> emilio: But maybe it's okay for the transition..<br> <TabAtkins> (I still don't understand the issue being discussed.)<br> <astearns> ack khush<br> <TabAtkins> khush: Impl-wise, we use a very similar path to opacity.<br> <TabAtkins> khush: Say the element has to be painted atomically. For elements tha toverflow you find out where they are relative to the VT element, and just use object-overflwo. The layout overflow of the element becomes ink overflow of the transition pseudo.<br> <TabAtkins> emilio: Okay that answers my question<br> <TabAtkins> JakeA: So proposed resolution is view-transition does not create a containing block for the element<br> <TabAtkins> astearns: Proposed resolution is that view-transition makes the element a stacking context, a grouping element, and a backdrop root<br> <TabAtkins> smfr: This applies at all times, not just while the transition is running, right?<br> <TabAtkins> JakeA: Yes, we think that's more consistent.<br> <TabAtkins> smfr: I think a note in the spec about the fixpos behavior would be useful.<br> <TabAtkins> TabAtkins: Are these effects different from contain:layout?<br> <TabAtkins> JakeA: Yes, layout contianment causes a CB as well.<br> <TabAtkins> flackr: I have a concern that this can make it easy for devs to make large cpatured elements, but there's another issue about that and shoudln't block this<br> <TabAtkins> flackr: Also this is different from transform, and I just wanted to make sure there weren't transform-relevant reasons to make it similar, but khushal's response answers that<br> <TabAtkins> astearns: Objections?<br> <TabAtkins> RESOLVED: A non-none view-transition-name acts similar to a non-1 opacity (stacking context, grouping element, backdrop root)<br> <fantasai> scribenick: fantasai<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8139#issuecomment-1422985284 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 February 2023 17:27:42 UTC