Using box-shadow in built-in appearances

[loxy]

Hi!

I saw that you are using mainly box-shadow for styling borders in the framework provided appearances.

Using box-shadow as a border can avoid layout shifts and offer smoother animations, but it may lead to challenges with performance, border-radius compatibility, and complex border styles (e.g., dashed, dotted). Additionally, it doesn’t impact the box model, which may require manual adjustments.

Was this trade-off—between layout stability and visual flexibility versus performance and compatibility—part of the design decision to use box-shadow over a traditional border? Are there specific scenarios you aimed to optimize for with this approach?

[waterplea]

Border cannot have subpixel transition and it being a part of the box model is a downside, rather than upside, since you would have to subtract it from padding. Say buttons have 1rem padding. If in outline appearance we used border then it would affect it and we would need to use calc(1rem - 1px). Visual appearance should not leak into layout since it is applied to all kind of elements, from inputs to buttons, to badges and chips. Not sure what you mean by border-radius compatibility. Box-shadow is exactly great for border-radius since it properly expands inwards and outwards. For complex border styles like dashed or dotted you can use outline, but be aware that damned Safari only started to support border-radius for those since v15, that's why we will probably migrate from outline to box-shadow in textfields. As for performance, I'm pretty sure JS and DOM manipulations are going to bottleneck and box-shadow wouldn't matter at all, but if you have some numbers to back up this concern — I would be glad to take a look.

[loxy]

No, everything fine. I wasn't up to date on this. Thank you!