Colour carries depth; shadows are the exception
Standard containers never carry a shadow. Depth comes from stepping through the container colour ramp, which keeps surfaces flat, crisp, and legible against the page floor. Only surfaces that genuinely float above the page (anchored overlays, modals, and the floating App sidebar) earn a shadow, along with a pinned table column that content scrolls under, and the elevation tokens below are the only ones that exist for it. Never write a literal box-shadow value in component CSS. There are two exceptions: the iOS glass on the mobile navigation components, which restates the platform’s own shadow so the mock reads as the real system chrome, and the hover lift described at the foot of this page.
Shadow tokens
Every token is defined per mode, with stronger opacity in dark mode so they still read against the near-black floor. The values below are the base theme’s. A theme can soften them, deepen them, or turn them off entirely, and a flat theme lets the hairline borders carry the depth alone.
Depth without shadows
Everything below the floating layer expresses hierarchy through background steps. Each level takes its own step on the neutral ramp, so a boundary reads from the contrast between adjacent surfaces, not from a lift. Which side of that contrast is lighter is the theme’s call: containers can sit brighter than the floor or deeper than it, and light and dark can go opposite ways. The contrast is the point.
The hover lift
Interactive Card and EntityCard navigation tiles lift on hover. That shadow is a deliberate navigational affordance, a signal that the whole tile is clickable, not an elevation pattern to copy onto static containers.