- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 26 Sep 2024 21:25:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Nested transitions: what happens if there is a mismatch?`, and agreed to the following: * `RESOLVED: Use Option 1 (last capture wins) when there's a v-t-group mismatch.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> noamr: So old document specifies an element is part of one VT group, new document specifies that element as part of a different VT group<br> <TabAtkins> noamr: we didn't find something that always works for this. and dont' htink UX-wise there's a reasonable default that always works, it's always somewhat weird.<br> <TabAtkins> noamr: better for the author to decide when there's a conflict<br> <TabAtkins> noamr: if they want the common ancestor to be a given group, they can just do that<br> <TabAtkins> noamr: we thought the right default, then, is to match v-t-class which uses what the new state describes, except for exit transitions<br> <khush> q?<br> <khush> q+<br> <TabAtkins> +1 from me, matching v-t-class sounds better<br> <TabAtkins> khush: sounds good<br> <astearns> ack khush<br> <flackr> q+<br> <TabAtkins> khush: one thing that was subtle to udnerstand for me is that if the new state wins, the ancestor you're now mapped under was never in your ancestor tree in the old dom<br> <TabAtkins> khush: [??]<br> <astearns> ack flackr<br> <TabAtkins> flackr: i think that option 4 is a nice option in many scenarios<br> <TabAtkins> flackr: you mentioned that devs can opt into the neaarest common ancestor<br> <khush> s/??/The screen state transform from the old state is mapped back to the space of the ancestor we're choosing in the new state<br> <vmpstr> the transform remap is the same even if we go with lowest common ancestor, no?<br> <TabAtkins> flackr: but there's no way to opt into option 4, where the old thing animates out in its container, to the new thing in its container<br> <TabAtkins> noamr: they can do that with two names, just making the two elements different names<br> <TabAtkins> flackr: can't have it animate between the positions tho<br> <TabAtkins> noamr: right<br> <TabAtkins> noamr: we looked into this, and it breaks too much of the semantics where you split the transition properties into two<br> <TabAtkins> noamr: didn't seem worth it for this edge case right now<br> <TabAtkins> noamr: but we might be able to address it in the future<br> <vmpstr> q?<br> <TabAtkins> flackr: i udnerstand it's technically complex, was just thinking that if none of the others are good defaults, and this does something you can't do otherwise, it might be a good direction to pursue<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: i'm not sure why the one your'e proposing is better than the other ones<br> <TabAtkins> noamr: It's not *better*, we think they're about equal, but it's consistent with v-t-class and other things<br> <TabAtkins> noamr: so it's easy to understand/remember that "last capture wins"<br> <TabAtkins> fantasai: did bramus have an opinion?<br> <TabAtkins> noamr: we've discussed it with him in the past<br> <ntim> q+<br> <TabAtkins> noamr: we've all come to this "can't think of anything better" position. nobody loves it, but users can decide what they want<br> <TabAtkins> khush: and if it doesn't work for you, you can do a common tree ancestor yourself<br> <TabAtkins> khush: using common ancestor autoamtically feels like more of a bug than intentional<br> <TabAtkins> flackr: my counter is option 4 presents *like* the thing they specified. the old thing wont' disappear because eit's suddenly clipped<br> <TabAtkins> khush: but option 4 is trying to sneak in a new feature into something that's otherwise an edge case<br> <TabAtkins> flackr: yeah<br> <TabAtkins> khush: not saying it's bad, it's just not straightforward to add and not worth doing so right this moment<br> <vmpstr> q+<br> <TabAtkins> flackr: if it's an error case, could we just say you don't do a transition?<br> <TabAtkins> noamr: we've been there with v-t-class, I think doing "last capture wins" is a better default. CSS usually tries to recover when possible.<br> <vmpstr> q?<br> <TabAtkins> khush: if it's a choice between option 4 and not doing a VT, I'd prefer not doing one<br> <TabAtkins> fantasai: so it would be a transition, but we woudln't independently capture this element<br> <TabAtkins> flackr: yeah, because ancestors disagreed. almost like you're matching on (name, ancestor) pair<br> <khush> q?<br> <astearns> ack ntim<br> <TabAtkins> ntim: I thi8nk last capture wins makes more sense than option 2 or 3<br> <TabAtkins> ntim: usually you want the current state of the Dom to apply, and that's what last capture does<br> <ntim> current state of the DOM and style<br> <TabAtkins> vmpstr: option 4 also loses cross fades, because they're split into two groups. so it breaks more than it fixes, I think. I also support last capture wins, it's more consistent<br> <noamr> q+<br> <astearns> ack vmpstr<br> <astearns> ack noamr<br> <TabAtkins> noamr: note this isn't necessarily an error condition, maybe something has changed and now you know what the right state is. you're course-correcting<br> <TabAtkins> astearns: so which was "last capture wins"?<br> <TabAtkins> noamr: option 1<br> <khush> +1<br> <TabAtkins> astearns: ready to resolve?<br> <TabAtkins> RESOLVED: Use Option 1 (last capture wins) when there's a v-t-group mismatch.<br> <TabAtkins> astearns: I heard chatter about option 4 being a new feature, should there be an issue for this?<br> <TabAtkins> noamr: yeah we can open an issue to explore<br> <TabAtkins> astearns: we could possibly wait until it's justified<br> <TabAtkins> ntim: waiting is my preference, yeah<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10631#issuecomment-2377967046 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 26 September 2024 21:25:42 UTC