What
An axis for how elevated surfaces draw their edge: border + shadow (dotUI today) vs ring-1 + shadow. Likely a grouped tweak (like translucent menus), not a per-component param.
Why
In the shadcn 8-styles study (Aug 2026): all eight styles render popovers, menus, and dialogs as ring + shadow; zero use a border. dotUI uses border + shadow everywhere. A ring sits outside layout — the hairline doesn't consume a pixel of the box — and reads differently against the shadow. This is visible on every overlay in the system and we have no axis for it; perceptually it's a bigger difference vs shadcn than any radius delta was.
Scope
popover, menu/select/combobox content, dialog/modal, command, tooltip — the surface + panel role groups from #579.
Open questions
- Semantic: does the existing
--color-border family drive the ring color, or does it need its own token?
- Default: keep border (dotUI identity) and offer ring, or flip the default to match the ecosystem?
What
An axis for how elevated surfaces draw their edge:
border+ shadow (dotUI today) vsring-1+ shadow. Likely a grouped tweak (like translucent menus), not a per-component param.Why
In the shadcn 8-styles study (Aug 2026): all eight styles render popovers, menus, and dialogs as ring + shadow; zero use a border. dotUI uses border + shadow everywhere. A ring sits outside layout — the hairline doesn't consume a pixel of the box — and reads differently against the shadow. This is visible on every overlay in the system and we have no axis for it; perceptually it's a bigger difference vs shadcn than any radius delta was.
Scope
popover, menu/select/combobox content, dialog/modal, command, tooltip — the surface + panel role groups from #579.
Open questions
--color-borderfamily drive the ring color, or does it need its own token?