- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 13 Jun 2024 13:59:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Proposal for a view-transition-tree property (name tbd)`, and agreed to the following: * `RESOLVED: use view-transition-group: normal | <ident> | nearest | contain, as described in the issue` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> vmpstr: in our current model we take the VT elements and flatten them, so the pseudo-elements that represent them are siblings in the pseudo tree<br> <TabAtkins> vmpstr: good in many ways, but makes some effects hard to do<br> <TabAtkins> vmpstr: like making a transitioning element be clipped by another transitioning element is impossible, but that's highly desired<br> <TabAtkins> vmpstr: so to solve that, would like to introduce a few props<br> <TabAtkins> vmpstr: v-t-tree: flatten | preserve<br> <TabAtkins> vmpstr: flatten is the default, today's behavior<br> <TabAtkins> vmpstr: preserve means the VT that preserve is on is a container for its descendants<br> <TabAtkins> vmpstr: for VTs started by the descendants of its element<br> <TabAtkins> vmpstr: v-t-parent lets me specify an ancestor as the element I want my VT to be a direct child of<br> <TabAtkins> vmpstr: escapes the v-t-tree property<br> <TabAtkins> vmpstr: takes auto, a vt-name, or none meaning use the root<br> <TabAtkins> vmpstr: we'd like the v-t-parent property to be independent of the tree property<br> <TabAtkins> vmpstr: So specifying parent is enough to trigger the containment, you don't need -tree on that ancestor<br> <TabAtkins> vmpstr: so v-t-tree is kinda syntactic sugar, avoids having to manually set v-t-parent on everything<br> <TabAtkins> vmpstr: some questions open so far:<br> <astearns> I think I would have expected reparenting to just determine where the thing was flattened<br> <TabAtkins> vmpstr: what to do if there's a topology mismatch between the start and end state<br> <TabAtkins> vmpstr: we could keep the old topology, maybe flatten mismatches, maybe error out<br> <TabAtkins> vmpstr: slight preference to keep old structure, except for entry animations which just parent to what they want<br> <khush> q+<br> <TabAtkins> vmpstr: another, should -parent be inherited? seems nice - surely an element's descendants also want to parent to the same element. but that doesn't play well with -tree<br> <bramus> see https://github.com/w3c/csswg-drafts/issues/10334#issuecomment-2163741673 for an example of that<br> <TabAtkins> vmpstr: if you have a -parent, and then a -tree on its descendant, *it's* descendants woul dhave an inherited -parent making them ignore the -tree<br> <TabAtkins> vmpstr: so weird<br> <TabAtkins> vmpstr: final, what's the acutal structure of the pseudo tree with this nesting?<br> <TabAtkins> vmpstr: one option is - ::group only has an image-pair right now. could have more groups as its chidlren?<br> <TabAtkins> vmpstr: a bit problematic for clipping, group is sized to the border box of the element but clipping defautls to happening on th epadding box<br> <TabAtkins> vmpstr: could introduce another intervening pseudo ::*-content, between group and image-pair<br> <TabAtkins> (or between group and child groups? i missed that)<br> <astearns> ack fantasai<br> <TabAtkins> vmpstr: I think khush doesn't like that<br> <TabAtkins> fantasai: read thru the issue quickly, i think i have a different proposal for the property<br> <TabAtkins> fantasai: i think the structure stuff still applies<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/10334#issuecomment-2165649094<br> <TabAtkins> fantasai: added ac omment<br> <TabAtkins> fantasai: Instead of having two props, have one, non-inherited<br> <TabAtkins> fantasai: v-t-group, puts you in mind of groups<br> <TabAtkins> fantasai: applies to any element with v-t-name<br> <TabAtkins> fantasai: initial value is normal, does current thing<br> <TabAtkins> fantasai: can specify ident, it groups this under that named group, like v-t-parent from your proposal<br> <TabAtkins> fantasai: auto value, also like v-t-parent<br> <TabAtkins> fantasai: both fo these also default their descendants to also be grouped under<br> <TabAtkins> fantasai: last value is contain, which doesn't group this element under anything, but defaults its children to grouping<br> <fantasai> view-transition-group: normal | <ident> | auto | contain<br> <TabAtkins> TabAtkins: it doesn't inherit because you actually want to inherit the element association, not the name<br> <TabAtkins> fantasai: right, say you have two descendants, one inside another, they'll be siblings in the thing they're rooting to, like normal<br> <bramus> q+<br> <TabAtkins> vmpstr: yeah if ident and auto both contain, i think that's problem solved<br> <TabAtkins> vmpstr: off the top of my head this sounds reasonable, seems to solve all the cases<br> <astearns> ack khush<br> <TabAtkins> khush: +1 offhand as well<br> <TabAtkins> khush: would be okay resolving for now and reviewing later<br> <TabAtkins> khush: two things to mention<br> <TabAtkins> khush: 1, fallback behavior for mismatch in topology<br> <TabAtkins> fantasai: suggestion - parent both to the nearest common ancestor<br> <TabAtkins> khush: that's what iw anted to come to<br> <TabAtkins> khush: your transform has to be related to the element you're parented under<br> <TabAtkins> khush: so we'll have a situation where the transforms are related to different elements, unsure if that's buggier than just flattening the whole tree<br> <TabAtkins> fantasai: say in one tree A is inside the ocntainer, in the other it's not - jsut parented to the root<br> <TabAtkins> khush: so you find the nearest common ancestor and reparent both to that<br> <TabAtkins> fantasai: yes, in this example they'd both parent to root<br> <TabAtkins> fantasai: [explains example]<br> <vmpstr> q?<br> <TabAtkins> khush: the weird case is you invert the relationships - in one tree you have A->B, the other is B->A. i guess they'd just root<br> <TabAtkins> vmpstr: problem is we don't necessarily know the old dom state by the time we have the new dom state. we don't keep it around<br> <TabAtkins> vmpstr: that could cause issues with common ancestry<br> <TabAtkins> bramus: how would that work for adding/removing elements/<br> <TabAtkins> bramus: say container withi overflow:clip, you add an element that'll be partially clipped, you want it in the container rather than in the root<br> <TabAtkins> fantasai: if it's added or removed, there's no conflict<br> <TabAtkins> khush: to vlad, since we only have to preserve the topology of things with a v-t-name, maybe we can cache that?<br> <TabAtkins> vmpstr: new dom can have new v-t elements. i htink if you keep the dom ancestor chain alive, you'll have enough info<br> <TabAtkins> khush: yeah, don't have to keep the whole topology, just things with a name<br> <TabAtkins> fantasai: and not even the actual dom relationships, just the vt tree hierarchy<br> <TabAtkins> vmpstr: but it can have new elements added that can serve as containers<br> <TabAtkins> fantasai: i think we dont' want to care about the dom, just the vt tree. it has parent/child based on v-t-group<br> <TabAtkins> fantasai: you build the tree on old, and on new, and compare for matches<br> <TabAtkins> fantasai: the doms didn't matter, just the tree you get<br> <TabAtkins> khush: another way, first construct the tree based on the old dom, then in the new dom some things that were in the parent move up the chain due to a mismatch<br> <TabAtkins> [cases too complicated, i'll have vmpstr write this]<br> <TabAtkins> astearns: Is this a separate issue once we decide the syntax, or does it depend on the syntax?<br> <TabAtkins> fantasai: separate<br> <TabAtkins> vmpstr: separate<br> <TabAtkins> astearns: okay so let's do syntax and do tree structure after<br> <TabAtkins> khush: happy to do separately. but one more point about tree in the good case<br> <TabAtkins> khush: i was hoping we could resolve on whether we have a new pseudo or what.<br> <khush> sgtm<br> <TabAtkins> bramus: question on syntax, should we rename 'auto' to 'nearest' to parallel with scroll animations? also has a 'nearest' keyword<br> <TabAtkins> fantasai: sure<br> <TabAtkins> astearns: objections?<br> <fantasai> PROPOSED: view-transition-group: normal | <ident> | nearest | contain as described in the issue<br> <TabAtkins> RESOLVED: use view-transition-group: normal | <ident> | nearest | contain, as described in the issue<br> <TabAtkins> khush: other issue, what if you want to clip the children underneath you, but not your own image<br> <TabAtkins> khush: if you try to use the group pseudo, it'll apply to both your children and your image pair<br> <TabAtkins> khush: by design, we do this becuase you have a dom hierarchy<br> <lwarlow> Wait does <ident> preclude adding new keywords in future? Should it be dashed-ident?<br> <TabAtkins> khush: but then stuff gets flattened in VT land<br> <TabAtkins> khush: if a DOM has overflow:clip or paint containment, it's clipping its contents, aka all of its children<br> <fantasai> lwarlow: it's the same as view-transition name, that was just a shorthand<br> <TabAtkins> khush: what doesn't get clipped by these is box decorations or other ink overflow from the box<br> <fantasai> s/shorthand/informal shorthand/<br> <TabAtkins> khush: so if you don't want to clip the element's image, but do want to clip the children...<br> <TabAtkins> khush: this happens bedause of a thing VT does which isn't great<br> <TabAtkins> khush: we tried to use these pseudos to as closely mirror the dom element in VT land<br> <TabAtkins> khush: and right now the images include everything, decorations included<br> <TabAtkins> khush: that's why we don't clip by overflow, dont' want to clip shadows<br> <TabAtkins> khush: so if you use this feature, either you overflow the ::group, so you shadows are clipped, or you don't, and your children aren't clipped<br> <TabAtkins> khush: so that's why we had a proposal for a pseudo that was just child VTs, you could overflow jsut that one<br> <TabAtkins> khush: i'm not a fan because it's still just working around something fudnamentally broken<br> <TabAtkins> khush: border-radius will still be in your image, but won't clip your children, for example<br> <TabAtkins> khush: there was a feature for a new capture mode that we punted on becaus eit was hard<br> <TabAtkins> khush: which is rather than put it all in one image, we split it.<br> <TabAtkins> khush: one image is just the contents, the group the mirrors the element by copying over properties<br> <TabAtkins> khush: so copying background-color, border-radius, box-shadow, etc<br> <TabAtkins> khush: then it's a legit mirror of the element, and with nicer animations<br> <TabAtkins> khush: if you have a small button growing into a larger widget, people want real animations rather than a scale up, looks nicer<br> <TabAtkins> khush: that mode would also fix the children clipping issue<br> <TabAtkins> khush: if you put overflow:clip on it, it'll clip the contents, the rest of the decoarations will be real css on the group pseudo<br> <TabAtkins> khush: we putned because it was hard to say what all you need to copy over<br> <TabAtkins> khush: but if we don't think it's a crazy idea, maybe we should fix that and get rid of the clipping problem<br> <TabAtkins> khush: instead of introducing a new pseudo to keep working around it<br> <bramus> q+<br> <TabAtkins> khush: this also happens with opacity/filter/etc. if things work in this new mode, the VT tree will more lcosely resemble what the element looks like<br> <TabAtkins> fantasai: I think that is quite a can of worms<br> <TabAtkins> fantasai: so if you want a filter, doesn't that affect the bg/border/content<br> <TabAtkins> khush: yes, that's what you want<br> <TabAtkins> fantasai: but you dont' have content, you ahve a snapshot<br> <fantasai> TabAtkins: if you blur an element, it blurs its contents and border etc.<br> <fantasai> TabAtkins: if filter was copied over to the group, it should just act identically as on a normal element<br> <TabAtkins> vmpstr: i think there's still a problem with inherited properties, like visibility<br> <TabAtkins> khush: my main pushback about a new pseudo is along these lines. it complicates the api surface, doens't solve problems like border-radius clipping, etc. so maybe we shoudl look into this other mode that fixes things properly<br> <TabAtkins> khush: otherwise we'll have another conversation like the size interpolation one<br> <TabAtkins> bramus: i think if you want to epxlore it we can test on a bunch of existing VT sites<br> <futhark> present-<br> <TabAtkins> khush: so should we resolve?<br> <TabAtkins> fantasai: I think we can leave that as an open issue<br> <TabAtkins> fantasai: I think either option isn't quite solid enough yet. one doesn't solve some issues, the other requires a lot of work<br> <TabAtkins> khush: if you don't have box decos that bleed out, then what is proposed would work<br> <TabAtkins> fantasai: that wouldn't clip to the border shape, so you alreayd have a problem<br> <fantasai> TabAtkins: I think we should epxlore it. not resolve until we figure out<br> <TabAtkins> fantasai: I think this issue is really long and mostly syntax, we should open a new one about the structure<br> <TabAtkins> khush: i can file a separate issue for the structure question<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10334#issuecomment-2165761156 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 June 2024 13:59:29 UTC