- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 21 Jan 2026 16:57:16 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-position-1] Interaction between trying position options and CSS transitions`, and agreed to the following: * `ACTION: Define "base style" concept in a spec somewhere` * `RESOLVED: fallbacks are based only on changes in base style, styles introduced in the Animations or Transitions origins are not considered` <details><summary>The full IRC log of that discussion</summary> <ydaniv> fantasai: we tried to clarify that while you're transitioning between states you don't want to calculate the fallback on every frame<br> <ydaniv> ... calculating fallbacks in intensive, you might be flipping during transition<br> <ydaniv> ... and which position is the end state...<br> <andruud> q+<br> <ydaniv> ... so we tried to clarify this, but with animations, where you have multiple keyframes ...<br> <fantasai> https://drafts.csswg.org/css-anchor-position-1/#suspending-fallback-animations<br> <astearns> ack andruud<br> <ydaniv> ... so currently you have to calculate on changes in keyframes, but not during a transition<br> <ydaniv> andruud: is the proposal is that when starting transition you calculate the fallback, and you keep it during trantions?<br> <flackr> q+<br> <ydaniv> fantasai: so check on start, check on end, and animate between the two, but not recalculate during transition<br> <ydaniv> ... when you know where you end up you calculate that<br> <ydaniv> andruud: I'm still not clear on when you see the new fallback<br> <ydaniv> ... you could transitioning width which could affect the left property<br> <ydaniv> ... and left is not trantiiong<br> <ydaniv> ... you could have an abrupt change on the left property<br> <ydaniv> ... I think you should see the end state right away<br> <ydaniv> fantasai: you have to have a change somewhere<br> <ydaniv> andruud: yes...<br> <astearns> ack dbaron<br> <ydaniv> dbaron: one of the tricky things is that you could have other style changes during transition<br> <ydaniv> ... one is the change properties you're transitioning, which could trigger other transitions<br> <ydaniv> ... and cases where not<br> <futhark> q+<br> <ydaniv> ... what happens when you have one that affects the transitioned properties which triggers something else that's not transitioned<br> <ydaniv> ... so your end state is not already valid<br> <ydaniv> fantasai: I think it's fine if you're intrupted and you don't consider the start state anymore<br> <ydaniv> dbaron: one thing is that in some case interuptions could work smoothly, but not sure whether that's an issue...<br> <astearns> ack flackr<br> <ydaniv> flackr: I have an alternative perhaps, for some other cases we used the base computed style, which is what you have before animations/transitions cascade<br> <ydaniv> ... could we use that as your end state, as your base style, which could be well-defined?<br> <andruud> q+<br> <ydaniv> fantasai: if you're transitioning between 2 styles, like right x to y<br> <ydaniv> ... I think you'd expect a smooth transition here, then you have to calc the fallback in base as end, wouldn't that create an abrupt change?<br> <ydaniv> fantasai: if your fallback style is transitionable, and in cases where some of properties are, the computed style of fallback ...<br> <ydaniv> flackr: I guess ideally we would calculate the from state using the before change style, I don't know if that's doable, but that's i the spec<br> <ydaniv> andruud: I think we already do<br> <ydaniv> ... changing the fallback is ...<br> <ydaniv> ... as long as the right proprety is transitioned, whatever you do to fallback start a transition, that will work smoothly<br> <ydaniv> ... not sure we want animation to start a fallback<br> <ydaniv> ... this is what we do in Blink already<br> <astearns> ack futhark<br> <ydaniv> flackr: sounds to me like it's possible, to use keyframes as something that result in a fallback<br> <ydaniv> fantasai: yeah, we don't have an issue with using the keyframes and base on that<br> <TabAtkins> (correct, what fantasai said)<br> <ydaniv> ... question is what you do when start an animation and stuck in a state where there's no animation?<br> <fantasai> s/with using/with not using/<br> <ydaniv> flackr: I think your base style should be updated in that case<br> <ydaniv> andruud: we don't have a concept yet for that base style in any spec, maybe we should have one<br> <astearns> ack andruud<br> <fantasai> ACTION: Define "base style" concept in a spec somewhere<br> <ydaniv> astearns: not entirely sure I followed<br> <ydaniv> ... one is what fantasai added above<br> <ydaniv> ... other is that we should have a fallback choice change during transition?<br> <ydaniv> fantasai: no exactly, style produced by transition/animation don't change fallback, only based on base style<br> <ydaniv> ... so changes caused animation/transition will not cause a change in fallback<br> <ydaniv> astearns: so first step would be to define that concept and continue from there?<br> <fantasai> PROPOSED: fallbacks are based only on changes in base style, styles introduced in the Animations or Transitions origins are not considered<br> <ydaniv> flackr: yes<br> <kizu> “Base style”, not to be confused with `appearance: base` style<br> <ydaniv> ... I think this is reasonable for transitions, and works for animations<br> <dbaron> andruud: I tried to define this in an old PR for container queries<br> <ydaniv> astearns: does that works?<br> <TabAtkins> +1, this works for me. awkward no matter what we do in some cases, but this feels simple enough<br> <ydaniv> flackr: SGTM<br> <fantasai> RESOLVED: fallbacks are based only on changes in base style, styles introduced in the Animations or Transitions origins are not considered<br> <ydaniv> astearns: any objections?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13048#issuecomment-3779671984 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 January 2026 16:57:17 UTC