- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 18 Jul 2023 18:31:18 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-2] Components participating in the transition need to leak info to embedding context`, and agreed to the following: * `RESOLVED: Have some way to assign a name to a VT and style differently based on it, details tbd` <details><summary>The full IRC log of that discussion</summary> <fantasai> khush: We've seen use cases where authors want to change view transitions based on state of the DOM<br> <fantasai> khush: some tutorial suggest setting up a class on the root element<br> <fantasai> khush: to get custom transitions<br> <fantasai> khush: Is this the most optimal way?<br> <fantasai> khush: or should we allow startViewTransition() to pass in a keyword<br> <fantasai> khush: which then gets propagated to e.g. a media query<br> <fantasai> khush: I don't know that it's worth making a custom feature for this, rather than just recommending using class names on the root<br> <fantasai> ydaniv_: The issue started as a perf problem, and then changed to a ?? API<br> <fantasai> ydaniv_: we have state that's under the HTML object. In order to lift that so that the DOM tree for the transition can be styled based on that state<br> <fantasai> ydaniv_: using the :has() selector<br> <fantasai> ydaniv_: but that's a big perf no-no<br> <fantasai> ydaniv_: putting that aside, maybe even if browsers can optimize that it's only styling the pseudo-tree for transitions<br> <fantasai> ydaniv_: but aside from preferred way, after DOM callback, to set attributes or ?<br> <fantasai> ydaniv_: there was also a thought for maybe on the next level, expose the state<br> <bramus> q+<br> <astearns> ack fantasai<br> <khush> Issue is correct<br> <TabAtkins> fantasai: i think it would be prettys traightforward to create this kind of tag in the arguments of th estartViewTransition() function<br> <TabAtkins> fantasai: easy way to expose it would be with ::view-transition-root() thing<br> <khush> You mean ::view-transition(foo)?<br> <TabAtkins> fantasai: it does feel like modifying the dom which isn't great<br> <TabAtkins> fantasai: modifying the dom to pass arguments is awkward even if it's performant<br> <TabAtkins> (yes, that's what was intended, khush)<br> <TabAtkins> fantasai: So if we can pass a name to startViewTransition() then select based on that name, it seems nicer<br> <TabAtkins> fantasai: I think people would probably also want it for cross-document stuff<br> <TabAtkins> fantasai: from urls A to urls B it's X class of transition<br> <TabAtkins> bramus: I was going to propose something similar<br> <astearns> ack bramus<br> <TabAtkins> bramus: the flag or label in JS which you can read in CSS<br> <TabAtkins> bramus: in addition to that maybe a MQ<br> <TabAtkins> fantasai: you can't do an MQ because you might have multiple VTs going<br> <TabAtkins> bramus: a CQ maybe?<br> <TabAtkins> fantasai: That's why I think having it be an argument in ::view-transition()<br> <TabAtkins> vmpstr: Problem with that is all the nested elements are accessed via the root element directly, so it's unclear to me how to limit a style to a group to only apply in this case<br> <TabAtkins> fantasai: might be able to just pass that directly in as a second argument?<br> <TabAtkins> (or define that ::view-transition-group() is *also* accessible under ::view-transition ?)<br> <TabAtkins> vmpstr: I'm also ok with MQs but agree it could be confusing with multiples VTs running<br> <TabAtkins> fantasai: With Tab's idea, nice thing is if Nesting allowed pseudos you could open up brackets and put them all inside of there<br> <TabAtkins> khush: We didn't want to have to express the entire pseudo tree, how would you target something deep?<br> <TabAtkins> vmpstr: You just put them under the ::view-transition, it's like having them come off of html<br> <TabAtkins> fantasai: let's talk about this on the break<br> <TabAtkins> fantasai: does anyone think we should *not* make this work, and rely just on class names?<br> <TabAtkins> YehonatanDaniv: I think it's very good to pass to the startViewTransition and recognize somehow in CSS, yeah<br> <noamr> q+<br> <TabAtkins> fantasai: k great let's try to come up with a proposal in this issue<br> <khush> q+<br> <TabAtkins> noamr: we ahve to think how this applies cross-document too<br> <astearns> ack noamr<br> <TabAtkins> fantasai: I think this gives you more options cross-origin, yeah, you don't have to try and modify the destination dom<br> <astearns> ack khush<br> <TabAtkins> khush: i want to make sure i udnerstand the reason for not using MQ<br> <TabAtkins> khush: MQ is nice because you can configure what things get a vt name based on type<br> <TabAtkins> khush: But using a ::view-transition() would only let you hit the pseudos<br> <TabAtkins> fantasai: You said earlier that you plan to have the ability to have multiple simultenous VTs. How does that work?<br> <TabAtkins> khush: If you have different VTs, each will have different originating elements<br> <TabAtkins> khush: So rather than html::view-* you'll have .foo::view-*<br> <TabAtkins> khush: so that's how it's different<br> <TabAtkins> fantasai: But the MQ can't match based on element...<br> <TabAtkins> Okay so they *would* all match in the MQ at once (and you'd use the selector to actually target the right element)<br> <TabAtkins> bramus: So if you have multiple transitions going on, the name you attach to each would ahve to be different<br> <TabAtkins> khush: I just want to have the MQ syntax on the table to discuss<br> <TabAtkins> fantasai: Confusing bit is just if you start two transitions, they both set the vt name, and they set it in the same subtree, it can get confused with each other<br> <TabAtkins> vmpstr: right MQ is global, these subtrees are very local. mixing the two seems prone to weird conflicts<br> <TabAtkins> khush: okay, seems fine<br> <TabAtkins> khush: you can always toggle some class names at the same time as you call startVT() with a name, sure<br> <TabAtkins> astearns: so should we resolve that we want a solution, and continue in the issue?<br> <TabAtkins> khush: yeah<br> <TabAtkins> astearns: objections?<br> <TabAtkins> RESOLVED: Have some way to assign a name to a VT and style differently based on it, details tbd<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8960#issuecomment-1640742768 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 18 July 2023 18:31:20 UTC