Shipping a production dark colour scheme
prefers-color-scheme now allows sites to follow an operating-system preference, but a usable dark theme needs semantic colour tokens, asset treatment, contrast testing and a stable user override.
Model colour by purpose
Create tokens for surface, text, border, link, focus, status and elevation instead of mapping every light hex value to a dark hex value. Preserve hierarchy without relying on subtle low-contrast grey differences.
Choose preference precedence
Use a stored user choice when one exists and the system preference otherwise. Apply the initial theme before visible rendering to avoid a light flash, while keeping the page usable if script or storage access fails.
Declare browser chrome support
Use color-scheme to allow form controls, scrollbars and other user-agent surfaces to adopt compatible colours. Check custom controls and native controls together rather than restyling only selected inputs.
Adapt media and shadows
Provide alternate logos or illustrations where transparency and dark details disappear. Reduce bright image glare selectively and redesign elevation cues that depended on dark shadows against a light page.
Test states, not screenshots
Verify text and non-text contrast, focus, visited links, validation, disabled controls, charts and high-contrast settings in both schemes. Include email, print and embedded third-party surfaces in the boundary record.
Dark mode is another supported visual state. Every new component must define and test it rather than inherit accidental colours.