- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 28 May 2025 16:42:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2]: Nested ::view-transition-group should have a container pseudo.`, and agreed to the following:
* `ACTION: Clarify L1 to encourage styling ::group() and not ::image-pair()`
* `RESOLVED: add ::view-transition-group-children() (open to better names), and copy border-sizing properties to it`
<details><summary>The full IRC log of that discussion</summary>
<emilio> vmpstr: we discussed this in the context of nested v-t groups<br>
<emilio> ... to add a container to the nested groups<br>
<emilio> ... with the purposes of clipping the nested groups<br>
<emilio> ... bunch of discussions on how to accomplish that<br>
<emilio> ... for the purposes of unblocking I'd like to split some resolutions<br>
<emilio> ... so (1) we need a new element, (2) naming and (3) sizing<br>
<emilio> ... proposal is to size it so that if we apply a clip you make the clip apply as in the original element<br>
<emilio> ... so size it to border-box and set border-color: transparent and copy border* properties (border-width/border-box/overflow-clip-margin)<br>
<emilio> ... that way if the author decides to apply a clip it'd clip the same way as the original element<br>
<emilio> ... noamr had a different proposal, to take the original element's clipping-region, and turn it into a mask, and apply that mask on top<br>
<emilio> ... that may work in some cases better than this copying, but is more complicated<br>
<emilio> ... so I'd prefer to resolve on copying the border props<br>
<emilio> ... and then open an issue to the mask<br>
<flackr> q+<br>
<emilio> ... I'd like some resolutions to get some early version of this into developers<br>
<astearns> ack fantasai<br>
<Zakim> fantasai, you wanted to ask some stupid questions because she forgot the answers<br>
<emilio> ... none of the solutions are ideal<br>
<emilio> fantasai: so what we have right now is group() and image-pair()<br>
<emilio> ... and we need another?<br>
<emilio> ... why do we need a separate group() and image-pair()?<br>
<emilio> vmpstr: we want to nest things from other elements within this group<br>
<emilio> ... naively those would be siblings of the original group<br>
<emilio> ... which you wouldn't clip the children<br>
<emilio> ... so that it wouldn't affect the clipping of the image-pair<br>
<emilio> fantasai: remind me why we added the image-pair()<br>
<emilio> vmpstr: for isolation, we blend old+new with plus-lighter<br>
<emilio> fantasai: so generally we don't recommend authors to style the image-pair()<br>
<emilio> ... just pretend it doesn't exist?<br>
<emilio> vmpstr: that is the case in my experience<br>
<emilio> fantasai: wanna make clear in the spec that authors should style group()<br>
<emilio> ... so if the author creates a transition between old/new versions of the grouping element, where the border is transitioning as step() rather than smooth, would this copied version of the border track that?<br>
<emilio> ... or would it end up unsynchronized?<br>
<emilio> vmpstr: so you mean the transition step() is the new/old() ones?<br>
<emilio> ... I don't think it'd be synchronize<br>
<emilio> ... in the simple case old/new they cross-fade to the other, so it doesn't animate borders, it blends the pixels<br>
<emilio> ... you can't cross-fade clips<br>
<emilio> ... with the mask approach you could cross-fade the masks I guess<br>
<emilio> q+<br>
<astearns> ack flackr<br>
<emilio> ... but even in the default case it might not be great<br>
<emilio> flackr: I'm supportive of the idea<br>
<emilio> ... if we don't need to customize this we might want this to be internal in order to change the mechanics?<br>
<emilio> vmpstr: I think that's very magical<br>
<emilio> ... something's clipping this but there's nothing there<br>
<emilio> ... it's maybe an option<br>
<astearns> ack emilio<br>
<emilio> ... maybe too magic for my taste<br>
<flackr> emilio: Good idea to split resolutions. I thought default was not clipping.<br>
<fantasai> emilio: Seems to me splittng resolution, allow new pseudo<br>
<fantasai> emilio: naming, I don't care very much<br>
<fantasai> emilio: specifics of sizing and stuff is the tricky thng<br>
<fantasai> emilio: I'd rather keep it simple and let authors use clip-path etc.<br>
<fantasai> emilio: especially if default case won't be great<br>
<fantasai> emilio: If you need to clip with rounded rect with border, you could use clip-path or something else<br>
<flackr> q+<br>
<fantasai> emilio: should also work in the negative direction<br>
<fantasai> emilio: seems like at least the first resolution would be uncontroversial, and would help make progress<br>
<emilio> vmpstr: unfortunately bramus not on the call<br>
<emilio> ... happy to resolve on adding pseudo+name for now then see if we can resolve further<br>
<astearns> ack flackr<br>
<emilio> flackr: Please resolve on adding the pseudo, but we need the border on it because the position of the descendants depends on having a border<br>
<emilio> ... if developers added that border it'd shift all the descendants so we need the border size as part of the copied props<br>
<vmpstr> +1<br>
<emilio> q+<br>
<astearns> ack emilio<br>
<fantasai> emilio: would it though?<br>
<fantasai> emilio: The groups are absposes, right?<br>
<fantasai> emilio: and I guess the idea is that the group would always be the containing block of these? but aren't we using transform to position and size these?<br>
<fantasai> flackr: yes but it's relative to the [missed]<br>
<vmpstr> s/[missed]/content<br>
<fantasai> emilio: Isn't that how all other view transition pseudos work?<br>
<fantasai> emilio: Doesn't it mess things up if you add a border to ::view-transition-group today?<br>
<fantasai> flackr: Yes, but you would add this border to replicate the original clip, but by adding border you would screw up the positions of the elements<br>
<fantasai> vmpstr: You wouldn't add the borders on the group element itself, because captured the pixels that overflow the border box<br>
<fantasai> vmpstr: not a typical use case<br>
<fantasai> emilio: right, but you might not need a border<br>
<fantasai> emilio: but ok, I guess, do other things affect padding vs border box?<br>
<fantasai> emilio: does border-image do something weird?<br>
<fantasai> noamr: no, only border-width really<br>
<fantasai> vmpstr: I'd like to leave this a little open, as in anything that does affect it<br>
<fantasai> vmpstr: if other things affect, we can add them<br>
<fantasai> emilio: I guess it's ok? It feels weird to account for existing borders in this pseudo.<br>
<fantasai> emilio: idea would be to change how positioning of inner things work, to account for the border, right?<br>
<fantasai> emilio: but maybe we can fix it more generally, so that if you add a border to any of these pseudo-elements...?<br>
<fantasai> emilio: I guess it's hard to know beforehand<br>
<fantasai> emilio: The inconsistency with all the other grouping pseudoes bothers me<br>
<fantasai> emilio: also copying the border-width is not too terrible<br>
<fantasai> emilio: I guess you also need to set border-style...<br>
<emilio> vmpstr: we can possibly copy border-{width,style}, set border-color to transparent<br>
<fantasai> vmpstr: Yes, we can possibly copy border-width and border-style, and set border-color to transpraent if it was set to something on the original element<br>
<emilio> vmpstr: border-width might not have an effect depending on the rest of the styles<br>
<emilio> ... details tbd but the idea would be to keep the border area without drawing the border<br>
<emilio> astearns: think I'm hearing consensus of adding the pseudo and maybe giving a name<br>
<emilio> vmpstr: would like to resolve on copying something details tbd<br>
<emilio> ... content-area-affecting properties like border-width, maybe border-shape-affecting props like border-radius<br>
<emilio> astearns: proposed name?<br>
<emilio> vmpstr: `view-transition-nested-groups()`? `view-transition-nested-content()`?<br>
<emilio> ... no particularly strong naming<br>
<flackr> +1 to content<br>
<fantasai> view-transition-group-children?<br>
<fantasai> emilio: content sounds better for some reasons, but you also want the padding area. nested-content seems fine. fantasai's suggestion also seems fine<br>
<emilio> fantasai: I think none are particularly great<br>
<emilio> ... I don't like nested content because a lot of the content is going to be captured outside<br>
<noamr> view-transition-content-area?<br>
<emilio> vmpstr: view-transition-group-children or content-area?<br>
<emilio> fantasai: children seems slightly better because it distinguishes the image-pair<br>
<emilio> ... content-area is weird because you want the padding<br>
<emilio> vmpstr: let's not reference specific boxes, and do view-transition-group-children?<br>
<emilio> PROPOSED: add ::view-transition-group-children() (open to better names), and copy border-sizing properties to it<br>
<emilio> fantasai: want to propose extending the spec with the suggestion to style ::group() and not ::image-pair<br>
<fantasai> ACTION: Clarify L1 to encourage styling ::group() and not ::image-pair()<br>
<emilio> RESOLVED: add ::view-transition-group-children() (open to better names), and copy border-sizing properties to it<br>
<fantasai> s/extending/clarifying<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11926#issuecomment-2916977161 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 28 May 2025 16:42:12 UTC