The supplied-asset problem
When a product ships a single logo file and lets CSS invert it at the theme boundary, something breaks quietly. A dark navy wordmark inverts to a pale yellow nobody approved. A logo with a drop shadow picks up a white halo. Fine strokes disappear into a dark background because they were drawn with dark-on-light contrast in mind and never had any other version.
The root cause is that most marks are still designed against white. White is the default artboard in every vector application, and it has been since desktop publishing established the metaphor. Dark mode as a second palette means the interface has two ground colours now — but the logo pipeline hasn't caught up. The mark arrives as a single export, and the engineering team does what they can with it.
filter: invert(1) is the most common patch. It works on simple black marks and fails on everything else, because inversion is a mathematical operation on pixel values, not a considered colour decision. A carefully weighted red that reads as urgent on white inverts to a cyan that reads as nothing in particular. A gradient built to suggest three-dimensionality inverts into its tonal mirror and the depth reads backwards. The CSS did exactly what it was told; the result is still wrong.
The fix is an asset decision, not a code decision. A logo needs two versions — one optimised for light ground, one for dark — and the implementation needs a mechanism to serve the correct file: prefers-color-scheme in a <picture> element, or separate token-referenced assets in a design system, or both. The dark variant often isn't a simple colour swap. Thin strokes may need to be slightly lighter because halation on a bright mark against a dark field makes them read as heavier and bolder than their actual weight. Colours shift in perceived saturation as ground colour changes, so a brand red that holds its energy on white often needs a small hue or lightness correction to feel equivalent on dark.
This is a production discipline as much as a design one. The brief has to specify both states. The handoff has to deliver both files. The QA pass has to check both themes. Any one of those steps can drop the dark variant, and when it does the invert patch re-enters quietly, and nobody notices until someone opens the app in a dark environment and the logo looks like a photographic negative of itself.
Two versions is not a large ask. Not having them is a visible gap every time the user's system preference disagrees with the designer's artboard.