Skip to main content
Question

Hover transition in Dev Mode always resolves to Mode 1's color, ignoring the active variable mode

  • September 3, 2026
  • 3 replies
  • 16 views

Hi everyone,

I'm running into an issue with the Transitions/Animation code panel in Dev Mode when using variable modes for accent colors.

Setup:

  • One color variable (e.g. "Accent/Background") with multiple modes — each mode represents a different accent color (Mode 1 = Mint, Mode 2 = Violet, Mode 3 = Amber, etc.).
  • The mode is set at the frame/instance level (not via component variants).
  • A "While hovering → Change to [hover value]" interaction is set up, using the same variable's hover-state color.

Issue 1 – Hardcoded hex instead of variable reference
The generated animation code in the Transitions panel shows the colors as hardcoded hex values instead of referencing the variable, e.g.:

@keyframes kf_..._background-color_0 {
  0%   { background-color: #7D1FB8; }
  100% { background-color: #0F8279; }
}

Issue 2 – Hover always resolves to Mode 1, regardless of active mode
More importantly: no matter which mode the frame is set to, the hover ("100%") keyframe always ends up at the Mode 1 value (#0F8279, mint) instead of the hover color that belongs to the currently active mode.

  • Frame set to Violet mode: 0% #7D1FB8 (correct, Violet) → 100% #0F8279 (wrong — should be Violet's hover value, shows Mint/Mode 1 instead)
     
  • Frame set to Amber mode: 0% #9F6823 (correct, Amber) → 100% #0F8279 (wrong — should be Amber's hover value, shows Mint/Mode 1 instead)
     

So the starting value correctly reflects the active mode, but the transition's destination color always falls back to Mode 1 — as if the hover interaction is resolving against the default mode instead of the mode currently applied to the frame.

 

Is this a known limitation of how Dev Mode resolves variable modes for animations, or a bug? 

Figma version: 126.7.10
Browser/OS: Desktop for macOS

Thanks!

 

 

3 replies

djv
Figmate
  • djv
  • Community Support
  • September 3, 2026

Hi ​@Caro4, thanks for reaching out! 

I understand the confusion here, so I’d be happy to help clarify. 
 

On the hardcoded hex, this one's a known limitation. Animated properties can't currently hold a variable binding. The value unbinds to a static color the moment it's key framed, so the Transitions panel has no token left to reference by the time it generates code. Tokenized motion export is something the team is actively looking at, though I don't have a timeline to share yet.

 

On the hover resolving to Mode 1, this is not expected behavior. Your read matches what I'd expect too. The destination value is resolving against the collection's default mode rather than the mode applied to the frame, so I'd like to get over to the team. A couple of things that would help us understand:

  • Does the hover land on the correct color when you run the prototype in presentation mode, or is it wrong there too? That tells us whether this is a codegen-only issue or something deeper in how the transition resolves modes.
  • What happens if you set the mode directly on the layer with the hover interaction, rather than on a parent frame? Worth a quick test; it may sidestep the fallback.
  • A short screen recording with both the left and right panels visible would be great, so we can see the variable setup and the generated code side by side.

Thanks again for flagging this. Let us know, and we can help get you connected with the team to investigate further. 

  • Caro4
  • Author
  • New Member
  • September 4, 2026

Hi ​@djv,

thanks for your quick reply!

I created a (not so) short recording to clarify your questions. 

Yes, the prototype view works perfectly fine and uses the right mode setting.
And no, it does not help to set the mode to the “prototyped” layer. 

Thanks for investigating on this.

 

djv
Figmate
  • djv
  • Community Support
  • September 4, 2026

Hi ​@Caro4, thanks for the additional details! 

These two answers help narrow things down a lot. The fact that the prototype animates to the correct color while only the generated code falls back to Mode 1 tells us the runtime is resolving your variable modes correctly and the issue sits specifically in how the code panel evaluates the destination value. That's a meaningful distinction, and it matches a pattern we've seen in a couple of other places where a panel resolves a variable against the collection's default mode instead of the mode actually applied to the layer. I can help get this in front of the right team.
 

Two last things that would help them pin down which code path is at fault:

  • Is the hover-state color an alias pointing into a different variable collection, or does it live in the same collection as the base color? Cross-collection aliases have some known constraints around default modes, so this would tell us whether we're looking at a bug or a documented limitation.
  • Is the layer with the hover interaction a component instance, or a plain frame?

One thing worth testing as a temporary solution: since the destination keyframe consistently falls back to whichever mode is first in your collection, temporarily reordering the modes so the theme you're handing off sits first should make the generated code correct for that theme. Not elegant, and you'd need to repeat it per theme, but it may unblock you if you need usable output this week.

 

On the hardcoded hex, that part remains a known gap rather than something new, so I'd treat the values in your prototype as the source of truth for now and swap the tokens in by hand. Thanks again for digging into this with me. Let me know, and I'll connect you with our technical quality team to investigate further. 

Terms & ConditionsAccessibility statement