Wheels logo not visible in dark mode

[chapmandu]

Describe the bug
Wheels logo is not visible on the wheels.dev in dark mode.

To Reproduce
Steps to reproduce the behavior:

1. Visit to wheels.dev after dark.
2. Try to see the logo.

Screenshots
If applicable, add screenshots to help explain your problem.

Smartphone:

• OS: iOS 26.5 iPhone 12
• Browser Safari

[wheels-bot]

Wheels Bot — Triage

Classified as bug.

The report describes observable wrong behavior on wheels.dev: "Wheels logo is not visible on the wheels.dev in dark mode" with a confirming screenshot (iOS 26.5, iPhone 12, Safari). Reproducible in isolation — view the landing site under a dark color scheme. This is a defect, not a feature/design question.

Suspected layer

view — the static-site presentation layer (web monorepo, not framework vendor/wheels/). The logo is rendered by the shared UI package: web/packages/ui/src/components/Logo.astro, invoked from web/packages/ui/src/components/Header.astro.

Fix sketch

Header.astro:21 calls <Logo variant="lockup" size="md" />, and Logo.astro:28 maps lockup to the dark-ink wheels-logo.png unconditionally. There is no color-scheme switching, so the dark logo is invisible on a dark background. A white asset (wheels-logo-white.png) and a lockup-on-dark variant already exist (Logo.astro:4,7,28) — the machinery is there, it's just never selected. Fix shape: make the lockup color-scheme-aware. Cleanest approach is to render both images and toggle via a prefers-color-scheme: dark CSS media query (so it works without JS and matches the iOS Safari case in the report); alternatively swap src based on the active theme. Likely-changed file: web/packages/ui/src/components/Logo.astro (and possibly Header.astro if the variant is plumbed through). Affects every site consuming the shared header (landing, guides, blog, etc.).

Confidence: medium

The report and fix shape are clear, but this lives in the web/ static-site/UI monorepo rather than a framework layer the propose-fix flow normally targets, and the exact dark-mode detection mechanism (CSS prefers-color-scheme vs. a theme toggle) needs confirming against the site's existing theming — so it's not a one-line mechanical change.

<!-- wheels-bot:triage:3264 -->
<!-- wheels-bot:triage-class:bug -->
<!-- wheels-bot:triage-confidence:medium -->

[wheels-bot]

Wheels Bot — No PR proposed (out of TDD-gated scope)

I analyzed this and the fix is clear and low-risk, but it lives entirely in the web/ static-site monorepo (web/packages/ui/src/components/Logo.astro). The bot's propose-fix flow is gated by bot-tdd-gate.yml, which (a) requires a CFML spec under tests/specs/, vendor/wheels/tests/specs/, or cli/lucli/tests/specs/, and (b) explicitly excludes web/ from counting as implementation. A static Astro asset has no CFML surface to spec, so a compliant draft PR is structurally impossible here — opening one would guarantee a red required check. Handing the verified fix to a human (routing through the web monorepo's own review + visual-baseline process) is the correct path.

Root cause

The site's dark mode is driven purely by CSS — web/packages/ui/src/styles/tokens.css:79 redefines --color-bg/--color-fg under @media (prefers-color-scheme: dark). There is no JS theme toggle and no data-theme attribute.

Header.astro:21 renders <Logo variant="lockup" size="md" />, and Logo.astro:28 maps the lockup variant to the dark-ink wheels-logo.png unconditionally. On a dark background the dark-ink lockup is invisible — exactly the iOS Safari case in the report.

The white asset (wheels-logo-white.png) and a lockup-on-dark variant already exist; they're just never auto-selected. The JS-free fix that matches the site's existing CSS-only theming: for the auto lockup variant, render both images and toggle them with the same prefers-color-scheme: dark query.

Proposed fix — web/packages/ui/src/components/Logo.astro

Drop the now-unused isLockup/src consts and split the lockup rendering:

{
	variant === 'mark' && (
		<img
			src={markPng.src}
			width={markSizes[size].w}
			height={markSizes[size].h}
			alt="Wheels"
			class:list={['wd-logo', 'wd-logo--mark', className]}
			loading="eager"
			decoding="async"
		/>
	)
}

{
	variant === 'lockup' && (
		<>
			<img
				src={lockupPng.src}
				height={lockupHeights[size]}
				alt="wheels.dev"
				class:list={['wd-logo', 'wd-logo--lockup', 'wd-logo--lockup-light', className]}
				loading="eager"
				decoding="async"
			/>
			<img
				src={lockupWhitePng.src}
				height={lockupHeights[size]}
				alt="wheels.dev"
				class:list={['wd-logo', 'wd-logo--lockup', 'wd-logo--lockup-dark', className]}
				loading="eager"
				decoding="async"
			/>
		</>
	)
}

{
	variant === 'lockup-on-dark' && (
		<img
			src={lockupWhitePng.src}
			height={lockupHeights[size]}
			alt="wheels.dev"
			class:list={['wd-logo', 'wd-logo--lockup', className]}
			loading="eager"
			decoding="async"
		/>
	)
}

And the <style> block:

<style>
	.wd-logo {
		display: inline-block;
		flex-shrink: 0;
	}
	.wd-logo--lockup {
		width: auto;
	}
	/* Auto color-scheme lockup: dark-ink in light mode, white in dark mode
	   (e.g. iOS Safari under a dark appearance — see #3264). */
	.wd-logo--lockup-dark {
		display: none;
	}
	@media (prefers-color-scheme: dark) {
		.wd-logo--lockup-light {
			display: none;
		}
		.wd-logo--lockup-dark {
			display: inline-block;
		}
	}
</style>

Notes:

• variant="lockup" (used by Header.astro, hence every site — landing, guides, blog, …) becomes color-scheme-aware automatically.
• Explicit variant="lockup-on-dark" keeps its existing always-white behavior; variant="mark" is unchanged.
• Pure CSS, no JS, no layout shift (the hidden image is display:none), works in the exact iOS Safari scenario reported.

Suggested follow-up for the human applying this

• Run pnpm format in web/ and refresh the visual baseline (pnpm visual:baseline) since the header renders on every page.
• Add a changelog.d/<slug>.fixed.md fragment, e.g. - Fixed the wheels.dev header logo being invisible in dark mode (#3264).