- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 23 Apr 2025 17:00:39 +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.`. <details><summary>The full IRC log of that discussion</summary> <ydaniv> vmpstr: in VTs we have a pseudo struct with group, under image-pair, under old and new<br> <ydaniv> ... in group we added capability to nest groups<br> <ydaniv> ... we found that you'll be able to clip in VTs that are not all flat<br> <ydaniv> ... we found it's hard to do if element has borders, you'd clip the group instead of area that you inteded<br> <ydaniv> ... proposal is to add a VT content or other pseudo elemnt that acts as the parent of all nested groups<br> <ydaniv> ... so you have an image-pair and another child, say content<br> <ydaniv> ... would allow you to clip just the group and not the content<br> <bramus> q+<br> <ydaniv> ... proposal is to size to padding box which clips the padding box of the originating element that created the group<br> <astearns> ack bramus<br> <ydaniv> bramus: wanted to say that I tried this in playground by faking it real elements, and having this extra element makes it much much easier for authors to achieve this clipping<br> <ydaniv> ... you can see in the playground, if you compare the code of element with hotpink <missed><br> <emilio> q+<br> <ydaniv> ... much more convinient with this extra pseudo<br> <astearns> ack emilio<br> <ydaniv> emilio: is that just a border that doesn't clip correctly?<br> <ydaniv> vmpstr: it would be captured in either old or new that nested under pair that's under group<br> <ydaniv> astearns: proposed resolution is to add a new VT container?<br> <ydaniv> vmpstr: happy to change the name, it's technically group container<br> <ntim> q+<br> <ydaniv> bramus: with the * that it doesn't include <missed><br> <bramus> s/<missed>/the outer group<br> <ydaniv> flackr: I think the name content is roughly consistent with the box model<br> <emilio> q+<br> <astearns> ack ntim<br> <ydaniv> ntim: one question, are there any alt. solutions to address this use-case?<br> <ydaniv> ... content is a better name than container cuase here it's a child of the group<br> <ydaniv> vmpstr: both a child of the group but contains other groups<br> <ydaniv> ,,, as for q, bramus can answer better, not easily, can have <missed><br> <astearns> ack fantasai<br> <ydaniv> fantasai: we got the VT group, and then for each group it contains a pair and old/new, and in each thing we animate will have its own nested<br> <ydaniv> ... within an existing groups<br> <ydaniv> ... now we're saying to separate the image-pair, and now have another grouping element around all nested transitions<br> <bramus> q+<br> <ydaniv> vmpstr: yes ....<br> <ydaniv> fantasai: in many cases a lot of the content will be in the image-pair<br> <ydaniv> ... so container make a lot of sense<br> <fantasai> s/a lot of/more/<br> <ydaniv> ... I think since a lot of content will be in the image-pair, calling it content will be confusing<br> <ntim> -1 to the specific word combination of `-group-container`<br> <ydaniv> astearns: wondering if there are no nested VTs, is this new thing going to be empty?<br> <ydaniv> vmpstr: good question, was thinking of having one that would be empty<br> <astearns> q?<br> <astearns> ack emilio<br> <vmpstr> s/having one that would/not having one that would/<br> <ydaniv> emilio: this would be the only pseudo that would have special size, or we don't need this special case?<br> <bramus> scribe+<br> <ydaniv> vmpstr: I only know of the VT's sizing, and yes, that would be the only case, the others are on border-box<br> <bramus> bramus: not having a pseudo if there are no nested groups is consistent with not having a new or old pseudo in some cases.<br> <ydaniv> emilio: sounds unfortunate, maybe we should allow sizing the groups?<br> <ydaniv> ... if you allow that then we could use them<br> <astearns> group-wrapper, group-parent…<br> <ydaniv> vmpstr: problem is if you size them then the border in the old, adding a clip will clip that<br> <ydaniv> emilio: doesn't that mean that the snapshot will overide the border?<br> <ydaniv> ... I guess the old and new are things that actually need the border<br> <ydaniv> ... would be nice to have a simpler use-case for this<br> <ydaniv> ... maybe fine..., to me seems to want to have a border and not clip<br> <ydaniv> ... my q, is this case worth adding the extra complexity?<br> <ntim> +1 to emilio, magic is annoying<br> <ydaniv> ... when you capture the snapshot old/new elements, the size is not necessarily size of border box, but ink overflow, so you need a size for the pseudo element that represents this<br> <ntim> `::view-transition-nested-*` is my probably my favorite pick for a name<br> <ydaniv> ... I assume it's a reasonable default, it's doable but I think it's unfortunate for special case<br> <ydaniv> vmpstr: it contains the nested elements in it, so what would size it to?<br> <ydaniv> ... if to border-box then elements at the border ...<br> <ydaniv> ... would you be ok with content box?<br> <ydaniv> emilio: groups do that<br> <ydaniv> ... the things you're snapshotting and the box model of the pseudo tree makes sense<br> <ydaniv> ... we're not discussing that<br> <ydaniv> vmpstr: current box model of the pseudo tree makes sense<br> <ydaniv> ... make the case that shouldn't be sized to border box?<br> <ydaniv> emilio: yea<br> <ydaniv> vmpstr: poissble<br> <ydaniv> ... overall, with nesting as it's specified right now you have the ability to clip your groups it's only possble if you clip yourself<br> <ydaniv> ... if the objection is only to sizing, to border box<br> <ydaniv> ... so probably to padding box, which is what I'd recommend, that is my sense<br> <ydaniv> astearns: I wonder would it make sense to have the box KWargs as params<br> <ydaniv> emilio: doesn't quite work, because the function selects different elements<br> <ydaniv> ... I do think that something along those lines that you can somehow specify how things are sized<br> <astearns> q?<br> <ydaniv> ... like ink overflow, maybe<br> <ydaniv> ... to me adding extra container is not big deal but feels like a smell, for a particular case<br> <ydaniv> ... maybe I'm misunderstanding<br> <ydaniv> ... feels to special for something that we should address differently<br> <ydaniv> ... haven't thought about this deep enough<br> <astearns> ack bramus<br> <ydaniv> bramus: wanted to address some remarks<br> <ydaniv> ... I will record what I'm showing in the playground and add comments<br> <ydaniv> ... why this extra element would make things easier<br> <ydaniv> ... it's a code smell but help a lot<br> <ydaniv> emilio: maybe we should allow the capture to be sized to padding rather than border<br> <ydaniv> ... feels like more general issue, maybe I'm wrong<br> <ydaniv> vmpstr: the part I'm missing, suppose you take clipping as an example, how else would you clip the group without clipping the content?<br> <ydaniv> emilio: if the container of the snapshot that sized to the border box, ...<br> <ydaniv> vmpstr: there's only one clip that clips both, they should have different clippings<br> <ydaniv> emilio: I guess I need to wrap my head around the tree<br> <ydaniv> flackr: another harder case is having shadows and decorations that go outside of the border box<br> <ydaniv> ... and shouldn't be clipped<br> <ydaniv> vmpstr: have a few diagrams in the issue you can respond to<br> <ydaniv> emilio: sounds good<br> <ydaniv> astearns: we'll take this back to the issue<br> <ydaniv> ... I suppose talk about the possiblity of changing clipping of everything else?<br> <ydaniv> vmpstr: yes and no (:<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-2824958330 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 23 April 2025 17:00:40 UTC