# Deferred Decisions & Tradeoffs

Decisions made during the theme customization system build. Each entry records what was deferred, why, and when to revisit.

---

## 1. Custom Color Picker UI — RESOLVED

**Decision**: Built a custom Theme Customizer panel (`src/customizer.ts`) accessible via Command Palette > "Customize Theme..." or View > Activate Command Palette.

**What it provides**: Native HTML5 color pickers, collapsible sections, per-field reset buttons, "modified" badges, live preview via the existing hot-reload system. Only shows the active theme's settings (not all 12). Reads/writes through `ISettingRegistry` — same persistence as the built-in Settings Editor.

**Why custom**: JupyterLab's RJSF-based Settings Editor has no color picker support (`"format": "color"` is ignored), no custom widget registration API, and shows all 99 properties in an unnavigable flat list.

---

## 2. Cursor Blinking

**Decision**: Do not expose cursor blink rate in v1.

**Why deferred**: Cursor blinking is controlled by CodeMirror 6's `cursorBlinkRate`, not CSS variables. Exposing it requires registering a CM6 extension via `IEditorExtensionRegistry` — a different integration pattern from everything else in the extension, which is CSS-variable-driven. Adds a new dependency.

**Revisit when**: After v1 ships. Implementation would add a `cursorBlinkRate` setting (0 = no blink, 530ms = default half-period) and register a CodeMirror extension that reads from the setting.

---

## 3. Shadow Intensity

**Decision**: Do not expose shadow intensity in v1.

**Why deferred**: Would need to parameterize `rgba(0, 0, 0, 0.3–0.5)` across ~10 shadow definitions (elevation z1–z24, toolbar, menu, cell active glow). The visual impact of shadows is subtle and the setting would need careful UX (a slider? a "none/light/medium/heavy" enum?).

**Revisit when**: A user requests it, or when we build the custom settings panel where a slider would feel natural.

---

## 4. Active-Theme-Only Settings UI

**Decision**: Show all 12 themes as collapsed sections under "Theme Customization" rather than only showing the active theme's settings.

**Why deferred**: Showing only the active theme would require `ISettingRegistry.transform()` to dynamically swap the visible schema based on which theme is selected. This adds complexity and may have edge cases (e.g., settings UI state when switching themes). The collapsed-sections approach is simple and works — you expand the one you care about.

**Revisit when**: After v1 validates that the settings structure is correct. Could also be solved by the custom settings panel (deferred decision #1), which could show a theme selector dropdown at the top.

---

## 5. Individual Terminal ANSI Colors

**Decision**: v1 exposes a single "Use Theme Colors for Terminal" toggle (default: on). No per-color ANSI overrides.

**Why deferred**: 16 individual ANSI color settings is a lot of surface area for an edge case. The toggle maps palette colors to ANSI automatically (red→ANSI red, green→ANSI green, etc.), which is the right default for most users.

**Revisit when**: A user specifically wants to customize individual terminal colors (e.g., make ANSI green a different shade from code string green).

---

## 6. Presentation Mode Font Sizes

**Decision**: Do not expose `--jp-code-presentation-font-size` or `--jp-content-presentation-font-size1` in v1.

**Why deferred**: Presentation mode is rarely used. The current hardcoded values (16px code, 17px content) work fine. Adding these settings would increase surface area for minimal benefit.

**Revisit when**: A user working in presentation mode requests it.
