Why we use the CSS property box-shadow instead of border in our app

If you inspect the html and CSS of the threads.com site, you might notice something peculiar. On a div with a border, you'd expect to see the CSS property border, but instead, you'll see box-shadow.

Why is that?

Figma vs. the browser

Our design system works on a 4px grid, which means our spacing—margins and padding—is a multiple of 4.

However, we noticed something kept breaking the grid. Designs would look great in Figma, but they'd be a few pixels off in the browser.

What we found was there's an inconsistency between Figma and browsers when it comes to spacing around borders:

• In design tools like Figma, borders do not take up space
• In web browsers, borders do take up space

What does that mean?

For example, suppose we want to create a box with the following specifications:

How it looks in Figma

• When selecting the frame, the total size is 40x40, but it does not include the 1px border.
• The total width of the two box together is 88px (40 + 40 + 8), where the 2px of border on left and right are not accounted in the width.
• The margin starts at the end of the left content (not the border) and ends at the start of the right content. This means between the two borders there is a margin of 6px not 8px.

How it looks in the browser

• The size of the left component is 42x42 (40x40 inner + 1px border on each side)
• The total width of the two squares is 92px (42 + 42 + 8)
• The margin starts and stops where the border starts in both of the squares

What problems does this cause?

Designers work in Figma, and Engineers work in the browser. This discrepancy creates friction between engineering and design, and makes it difficult to maintain consistency across the product. This creates issues such as:

• Components do not fit properly since they take up more space than expected by design.
• Frequent back and forth between design and engineering during a polish pass since elements do not align correctly.
• One engineer can work with design and fix the implementation to match the specs under "one way the browser would implement it to match Figma," but the next engineer working on the feature notices the spacing does not match Figma and changes it.
• This breaks the common language that design and engineering strive to have. When talking about numbers and spacing one of us will need to account for how the other platform works.

What options did we consider to reconcile the differences?

Engineering adapts to the design system

With this solution, we would create a system where engineers understand this discrepancy and know how to update the spacing based off the Figma file. For example, they'd write the CSS:

We could create helper components and functions that make this easier to do this such as creating a div wrapper that transforms the spacing input based on whether a border has been defined. However, this would cause a discrepancy between the code and inspector, which makes it difficult to debug UI related bugs.

Design and Engineering both use box-shadow instead of border

Borders in Figma act just like box-shadows in browsers. In this solution, both systems would stop using borders completely and only use box-shadows to represent them. For example border: 1px solid black is equivalent to box-shadow: 0px 0px 0px 1px black.

Using box-shadow gives an effect of a border while taking up no space, which lets the remaining element attributes work as expected. Even though border and box-shadow are basically the same thing in Figma, Design would only use box-shadow to ensure consistency between the team and to ensure we have a common language between design and engineering.

What approach did we take?

We decided to go with Option . Design and Engineering use box-shadow instead of border in both Figma and the browser.

With this approach, engineers can copy the css properties directly from Figma instead of needing to know how to convert a border to a box-shadow.

As a result, when we polish a section of the frontend, it's much easier to make our designs pixel perfect. Design and Engineering speak a common language, and we all move faster together.