- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Mar 2023 15:50:43 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-view-transitions-1] Define the constraints which must be satisfied by a named element during the transition`, and agreed to the following: * ``RESOLVED: If an element is involved in a transition, the `view-transition-name` constraints are enforced during the transition`` * `RESOLVED: Conditions are checked per-frame; transition is skipped if other constraints are broken` <details><summary>The full IRC log of that discussion</summary> <JakeA> A view-transition-name value that isn't none gives an element stacking context, grouping element, backdrop root, similar to non-1 opacity, as view transitions need these constraints.<br> <emeyer> JakeA: If you give an element a transition name that isn’t none, it acts as if opacity is not 1<br> <fantasai> s/Topic:/Subtopic:/<br> <fantasai> s/Topic:/Subtopic:/<br> <fantasai> i/Subtopic: [css-view-transitions-1] Capturing/Topic: View Transitions<br> <RRSAgent> I have made the request to generate https://www.w3.org/2023/03/15-css-minutes.html fantasai<br> <emeyer> …Name is only checked during transition, but because the new view is live, we need to check constraints per frame<br> <emeyer> …If constraints are not satisfied mid-transition, element is dropped from the rest of the transition<br> <emeyer> …If an element isn’t rendered during setup, it’s ignored<br> <emeyer> …If an element becomes fragmented during transition, it’s dropped<br> <emeyer> …How do we check these conditions?<br> <emeyer> …Option 1: we assert extra conditions, then check to see if the view transition name is not none<br> <emeyer> …If a name ever becomes none, element is dropped<br> <emeyer> Option 2: We assert these all individually, regardless of name<br> <flackr> q+<br> <astearns> ack flackr<br> <emeyer> flackr: Option 3, if an element is undergoing view transition, it is subject to the constraints<br> <khush> I'd be ok with that.<br> <emeyer> JakeA: We can’t enforce rendering and we wouldn’t enforce fragmenting<br> <vmpstr> +1<br> <emeyer> flackr: Right, we could continue to enforce name-based constraints<br> <astearns> ack fantasai<br> <emeyer> TabAtkins: My preference as well<br> <emeyer> fantasai: That makes sense; other thought I had was if the name changes at all, I wouldn’t be surprised if the transition is suddenly dropped<br> <emeyer> JakeA: We avoided that because it means we can’t deal with elements that suddenly gain a transition name<br> <emeyer> fantasai: I’m not saying you’d start a new transition, I’m saying if someone messes with names, it should be dropped<br> <emeyer> JakeA: If a paragraph isn’t in a transition and halfway through JS gives it a name, should it be ignored?<br> <emeyer> …If we deal with every element changed names, then you have to check every frame<br> <emeyer> astearns: It sounds like Option 2, except names are kept throughout the transition and so need to be checked?<br> <emeyer> JakeA: I think people like flackr’s option<br> <emeyer> …I’m happy with that<br> <khush> +1<br> <emeyer> fantasai: Wouldn’t you also be enforcing that it’s not fragmented?<br> <emeyer> JakeA: We would skip the transition in that case<br> <emeyer> fantasai: What if a thing becomes fragmented partway through? Would you just ignore that?<br> <emeyer> JakeA: The new views are live and updated per frame<br> <emeyer> …If an element becomes not-renderable…<br> <emeyer> fantasai: I get it<br> <emeyer> astearns: Option3<br> <JakeA> If an element is involved in a transition, the ``view-transition-name` constraints are enforced during the transition<br> <JakeA> It's skipped if other constraints are broken<br> <JakeA> (eg rendering and now fragmenting)<br> <emeyer> RESOLVED: If an element is involved in a transition, the `view-transition-name` constraints are enforced during the transition<br> <emeyer> RESOLVED: Conditions are checked per-frame; transition is skipped if other constraints are broken<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8548#issuecomment-1470292414 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 March 2023 15:50:45 UTC