Figma Shadow Bugs Introduced Feb 26th. AFFECTED: Dev Mode & CSS Copy

Both

filter: drop-shadow
box-shadow:

Are also both discarding any spread values from the code.

Hey @Court_Kizer, thanks for flagging this!

We’ll pass this onto our Dev Mode team to review and investigate.

Hey @Court_Kizer,

Tom from Figma here, is there any way you can DM a link to a file with a copy of the components that have the shadows so we can take a look on our end. I’m having a convo with @dvaliao and the product team about this.

Cheers,
Tom

Tom,

I can. The bug is still persistent. It’s bad enough that our entire team moved to Zeplin for Dev mode activities until this can be resolved.

Tom I sent you a DM with a file of several examples and gave you full edit permissions.

Anyone else on the thread wanting to verify and see the bug, I’ve made a Figma with view permissions only that you can use to test: https://www.figma.com/file/stWVyiiZJ2v3zZJHt27vbe/Button-Shadow-Bug-Test?type=design&node-id=0%3A1&mode=design&t=1AOs3WI2D3uM8LkS-1

@Court_Kizer Do you have the examples of the check and radio boxes you can drop into that file? I can only see box-shadow properties on the ones you sent though and trying to figure out what you might be seeing.

@Tom_Lowry Sure I can add them in. Though my checkboxes and radio buttons are entirely made from box shadows too. Doesn’t effect the bug to turn on the strokes.

@Tom_Lowry Were you able to confirm the bug 🙂

Hey @Court_Kizer,

Thanks so much for sharing this file. I had a chance to take a look and try to work out what is going on.

Re: spread properties being missed:
I cannot seem to reproduce a case where a spread value is shown in Figma, but not in the code output of a box-shadow.

One thing looking into did highlight is that the order of the drop shadows is being reversed in the generated code via Dev Mode, I wonder if this what is causing the confusion around spread? (I have filed a bug and can update this thread when fixed)

Re: some of the shadows not being copied
This one is a bit tricky to explain. There are some differences between our older viewer code gen vs. Dev Mode code gen. Both are correct in terms of the styling of the element.

4 of those 7 shadows are not contributing visually to the shadow because they have no spread, offset, or opacity. In the free/viewer code, we are eliminating any of the shadows that are not visible. We do show them all in the Dev Mode code. There is not do to a limit. Make a change that makes one of those shadows visible (opacity + offset value) and you will see it in the code from the context menu outside of Dev Mode. That said, I think there are some use cases where showing shadows in the code that are not visible is value (like for CSS animation). I’ve filed this one with the team as well and can keep you posted. Quick visual to explain what is happening:

Re: box-shadow vs. filter
In all of your button examples I am seeing box-shadow which seems right!

With the radio/checkboxes, what is happening here is a little more complex and resulted in some good feedback for the team. Your approach is solid, re: doing it with frames (so that you get box-shadow/spread).

With Dev Mode we introduced some logic for “icon detection”. Square frames with vectors inside are part of that heuristic. The idea here was to make it easier to detect and surface icons as exportable assets even when the user hasn’t added export settings, and to make them easier to select (so developer’s export the entire frame and not just the vector inside). But it looks like your radio/checkbox buttons are getting captured in this and it is rendering a filter: drop-shadow property. I flagged this with the team as well.

In the interim, one workaround you could currently do, is turn the frame with the shadow on it, to an Auto Layout frame (with fixed height/width). That will prevent it from being captured by the icon-detection stuff and should render a box-shadow property.

Appreciate you sharing the files—this has been really helped uncover some good stuff to fix/make better.

Awesome thanks for sharing. I would very much urge the team much to copy shadows with zero values. I can show you the rendered HTML, and you can see that those 0 value drop-shadows are critical to what it looks like in the browser.

The also slightly look different in Figma if I were to say apply another drop shadow on them. This is because of how DOM in browser (including Figma) render.

Currently:
I cannot copy box-shadow property in dev mode or from the css menu and apply Figma’s outputted CSS to a single DOM object (I have a single object in Figma) so it should work the way I expect.

Right now Zeplin (Gulp) outputs it correctly with all the css drop-shadows copied.

The only time Figma should not copy a drop-shadow property into a css box-shadow is if it is hidden by tapping the “Eye-con”

@Tom_Lowry I played with the bug a few hours this weekend. I realized that 90% of this bug is an old regression bug that I reported 2 years ago. It’s mostly because Figma still puts shadows out of order when exporting in both dev mode, and CSS box shadow properties.

This doesn’t happen with other tools analyzing the Figma file. I really want to see this fixed. It means devs can’t reliable use any code generated from Figma with a shadow.

Let me know how I can help. I’m happy to make a video clearly explaining it or anything that would get this up the chain faster.

Hey @Court_Kizer. We had a deploy today that should have fixed the shadow order issue. Can you confirm on your end.

Also lmk if the auto layout frame workaround on your radio/checkbox components solves the box-shadow + css code issue you encountered.

@Tom_Lowry Awesome fix with the ordering. This was directly copy and pasted and it works: Tailwind Play

@Tom_Lowry There is a bug when adding a new Effect. When you click “+”, the animation appears from the bottom, but the new shadow is actually at the top of the stack. Please remove the animation or adjust it to reveal from the top. This is confusing for UI enthusiasts.

Bug:

i