@gurupanguji

Leica Black Theme Design

Date: 2026-03-19 Repo: gurupanguji.github.io Branch: feature/leica-black-theme Status: Approved design

Goal

Add a second site theme inspired by Leica black paint, while preserving the current silver-chrome look as the light theme. The site should:

• Default to the visitor’s system theme on first load
• Let the visitor switch between chrome and black
• Keep the control visually quiet in the shared header
• Add a small explanatory finish module on the homepage
• Preserve the site’s “Das Wesentliche” restraint

Design Direction

The current theme already uses a material story: off-white surfaces, chrome-like borders, Leica red, and sparse editorial typography. The dark theme should extend that same logic instead of behaving like a generic dark mode.

Light theme

• Keep the current silver-chrome identity
• Retain off-white surfaces and black-chrome text
• Continue to use Leica red as the main accent

Dark theme

• Use black-paint inspired surfaces rather than pure black
• Use graphite and charcoal layers for depth
• Introduce moderate brass accents in small, intentional places
• Keep Leica red as the primary accent
• Avoid neon contrast or heavy glow

Brass should stay restrained. It can appear in separators, active states, focus rings, and the homepage finish module, but it should not compete with the red accent or become a recurring decorative color on every surface.

Architecture

Use one shared theme engine for the whole site.

Theme source of truth

• Store semantic design tokens in assets/css/style.css
• Apply the active theme through a data-theme attribute on the root element
• Use chrome and black as the explicit user-facing theme values

Default behavior

• On first visit, derive the theme from prefers-color-scheme
• If the user manually chooses a theme, persist that override in localStorage
• Keep an internal system fallback path in code so the site can respect system preference when there is no stored override

Paint timing

• Use a tiny inline bootstrap script in page heads to set the root data-theme before the main stylesheet paints
• Prevent a flash of the wrong theme on first render

No-JS fallback

• If JavaScript is unavailable, the site should still render cleanly in the current light theme
• If localStorage access fails, fall back to system preference and keep the layout stable

UI Components

Shared header control

Add a compact finish control to the shared header across the site shell.

Requirements:

• Keep the control visually quiet
• Make it feel like a finish selector, not a settings widget
• Expose the two explicit options: Chrome and Black
• Support mouse, touch, and keyboard interaction
• Include accessible labels and state

The approved direction is the quieter header treatment paired with a richer homepage explanation. This control applies to pages that already use the shared sticky header. The homepage remains headerless in this pass.

Homepage finish module

Add a small editorial module on the homepage near the intro and nav cluster.

Requirements:

• Explain the finish choice with slightly more ceremony than the header
• Include the homepage’s own interactive theme chooser so visitors can switch finishes there without relying on an interior page header
• Reinforce the Leica material metaphor
• Stay compact and aligned with the existing home layout
• Use brass in a measured way to support the black-paint story

This module should feel like a considered part of the homepage composition, not a floating settings box.

Theme Tokens

Refactor the shared stylesheet to use semantic variables instead of page-specific hard-coded grays where possible.

Expected token groups:

• Page background
• Surface background
• Elevated surface background
• Primary text
• Muted text
• Border
• Header glass background
• Header border
• Dot-grid color and opacity
• Accent red
• Accent brass
• Hover and active states
• Code or quote surface where needed in post layout

The goal is to let most pages inherit the theme change through variables instead of duplicating dark-specific rules.

Affected Files

Primary shared layer:

• assets/css/style.css

Pages and templates that likely need follow-up replacement of hard-coded colors:

• index.html
• about/index.html
• reviews/index.html
• _layouts/post.html

Pages to verify and patch if needed because they duplicate header or page-specific styling:

• reviews/camera/fujifilm/x100vi/index.html
• reviews/camera/leica/m11-p/index.html

Interaction Model

Initial load

1. Read stored theme override if present
2. Otherwise read prefers-color-scheme
3. Set root data-theme
4. Render the matching control state

Manual theme change

1. User activates Chrome or Black
2. Update root data-theme
3. Persist choice to localStorage
4. Sync all visible controls on the page

The homepage module control and the interior header control must always reflect the same active theme.

Accessibility

• Controls must be reachable by keyboard
• State must be announced through accessible text or ARIA state
• Contrast must remain readable in both themes
• Focus treatment must stay visible, including in dark mode

Visual Rules

Shared rules

• Preserve restraint
• Keep typography and spacing stable between themes
• Avoid adding decorative clutter
• Let material and contrast do the work

Dark theme specific rules

• Prefer softened black-paint surfaces over flat black
• Use warm brass sparingly
• Keep red clean and precise
• Maintain enough separation in sticky header glass, borders, cards, and feed rows
• Keep the dot-grid visible but quieter than the light theme version if needed

Risks

Inline style drift

Several pages use inline style blocks with hard-coded colors. If these are missed, dark mode will look inconsistent or break readability.

Mitigation:

• Replace literal colors with semantic variables during the implementation pass
• Verify each major page type after the shared CSS change lands

Header duplication

The header markup is duplicated across several pages instead of being centralized in one include.

Mitigation:

• Keep the control markup small and standardized
• Patch all repeated header instances in the same implementation pass

Theme flash

If the root theme is applied too late, the site will flash light before dark.

Mitigation:

• Set theme in a bootstrap script before stylesheet paint

Verification Plan

Run a local Jekyll preview and check at least these views in both themes:

• Homepage
• About page
• Blog archive
• Post layout
• Reviews index
• Leica review page
• Fujifilm review page

Check:

• Sticky header translucency
• Border and text contrast
• Dot-grid visibility
• Hover states
• Brass restraint
• Mobile and desktop widths
• Theme persistence after reload
• System-default behavior when no manual choice exists

Out of Scope

• Any redesign beyond the approved theme and control work
• Structural content rewrites
• Additional personalization or settings surfaces
• Expanding the theme system to more than the two finishes exposed in the UI

Implementation Summary

Build a semantic token-based theme layer in the shared CSS, set the default theme from system preference, persist manual overrides, add a quiet two-state finish control to shared headers, add a small homepage finish module, and patch page-specific inline color rules so both Leica-inspired finishes remain coherent across the site.