mikaelvesavuori/figmagic

Drop-shadow values appear in reverse order

alehar9320 opened this issue · 4 comments

Describe the bug
When retrieving token values for shadows from an object with two drop-shadow properties set, the order is reversed.

To Reproduce

  1. Go into Figma
  2. Duplicate Figmagic's Figma document template
  3. Perform the documented steps to make Figmagic retrieve tokens from the Figma document using the Figma API
  4. View the output for the token called Shadow Deep (multiple) inside shadows.ts

Expected behavior
The order of values shall be the same as in Figma. In other words, the drop-shadow that is defined first shall have its values occur first. The drop-shadow that is defined second, shall have its values appear second.

Screenshots
image

The result from Figmagic (reversed order)
Note that the drop-shadow that appears first in Figma has the percentage value of 17%. That now appears last of the values.

// THIS FILE IS AUTO-GENERATED BY FIGMAGIC. DO NOT MAKE EDITS IN THIS FILE! CHANGES WILL GET OVER-WRITTEN BY ANY FURTHER PROCESSING.

const shadows = {
 [...]
 "shadow-deep-multi": "0px 4px 20px rgba(0, 0, 0, 0.10), 0px 4px 4px rgba(0, 0, 0, 0.17)",
} as const

export default shadows;

Desktop

  • OS: Windows
  • Browser: N/A
  • Version: 10
  • Figmagic version: 4.2.21 (also present on 4.0.0).

Additional context
The issue originates from that the Figma API returns them in reverse order. Can be seen by opening figma.json.

Hi! Thanks for informing of the issue. Does this cause visual defects?

Unless I've missed something, the result is that the order of the shadows is reversed, when implemented using the token from Figmagic. Due to that the Figma API returns them in the reversed order (seen in figma.json).

When you use the inspect mode in Figma, the order is as one would expect. The first drop-shadow property (Figma Design mode) is inserted into the box-shadow property declaration first (Figma Inspect mode).

image

Here's an example of a visual defect (reversed order of shadow values in box-shadow).

Another problem is that Figma calls everything Drop-shadow, while translating the design into box-shadow or drop-shadow CSS dependent upon whether it's a ~ shape or a vector graphic. See blog post from the Figma developer who built the feature.

This means that if Figmagic is used to define shadow tokens, it should be recommended to only have one drop-shadow definition per rectangle. To maintain compatibility with both drop-shadow and box-shadow CSS. The exception would be if there is a clear distinction between tokens to be used with box-shadow and drop-shadow. As drop-shadow can only accept a single shadow parameter. Any token that has two values will simply be incompatible with drop-shadow.

Drop-shadow is likely the preferred choice among developers.

Solid commentary!

The ordering part is fixed in v4.3.0-alpha.0 that you are free to try out – it's being pushed to NPM as I write this. Note that the fix is part of a larger pack of changes, but nothing that should hinder you.

This should be handled in 4.3.0 which is now released.

The update fixes the reverse ordering, and I've added your note on usage to the (updated) docs.

Thanks! Feel free to get back in touch should something come up.