Problem
icons.sketchi.app has a light/dark preview toggle, but the icons themselves are not adapted — they are rendered as-is. Many brand marks are monochrome black (or near-black) and effectively disappear against a dark surface; a few are white-on-transparent and disappear against light.
Naive CSS filter: invert() is not acceptable: it would wreck multi-color brand marks (Google, Slack, Firefox) and change brand colors, which is both ugly and a trademark-usage problem.
What "intelligent" needs to mean
Some classification per icon, likely precomputed in the manifest at build time rather than at render time:
- Monochrome dark — safe to invert or recolor to
currentColor in dark mode.
- Monochrome light — safe to invert for light mode.
- Multi-color brand mark — never recolor. If contrast is insufficient, put it on a neutral chip/plate instead of touching the artwork.
- Has its own light/dark variants — some brands ship both; prefer the official variant.
The manifest already carries per-icon metadata (aliases, keywords, viewBox, bytes), so a colorMode or contrastStrategy field is a natural addition, computed by the icon pipeline.
Open questions
- Is per-icon classification derivable reliably from the SVG source (count distinct fills/strokes, detect near-black/near-white), or does it need review?
- Should the same metadata be exposed through
/api/icons so agents and downstream consumers get it too? Probably yes.
- Does this interact with #288 — logos inside diagram nodes will hit exactly the same problem once diagrams have dark backgrounds.
Priority
Future state. Raised by the product owner as a desire, explicitly not urgent, because the difficulty is unknown until the classification approach is proven.
Problem
icons.sketchi.apphas a light/dark preview toggle, but the icons themselves are not adapted — they are rendered as-is. Many brand marks are monochrome black (or near-black) and effectively disappear against a dark surface; a few are white-on-transparent and disappear against light.Naive CSS
filter: invert()is not acceptable: it would wreck multi-color brand marks (Google, Slack, Firefox) and change brand colors, which is both ugly and a trademark-usage problem.What "intelligent" needs to mean
Some classification per icon, likely precomputed in the manifest at build time rather than at render time:
currentColorin dark mode.The manifest already carries per-icon metadata (
aliases,keywords,viewBox,bytes), so acolorModeorcontrastStrategyfield is a natural addition, computed by the icon pipeline.Open questions
/api/iconsso agents and downstream consumers get it too? Probably yes.Priority
Future state. Raised by the product owner as a desire, explicitly not urgent, because the difficulty is unknown until the classification approach is proven.