The CSS Variable Contract: How MOLTamp Themes Actually Work
A technical deep dive into the --t-*, --c-*, and --effect-* variable system that powers every MOLTamp skin.
Every MOLTamp skin is a conversation between two parties: the skin author and the shell. The language they speak is CSS custom properties. Here's how the contract works.
Three Namespaces
MOLTamp reserves three variable prefixes. Every skin uses them, and the shell reads them:
— Terminal Colors (21 variables)
These control the terminal emulator's palette: foreground, background, cursor, and the 16 ANSI colors (normal + bright variants).
The terminal emulator (xterm.js) reads these at skin load time and applies them. Change and every green terminal output changes.
— Chrome Colors (6 variables)
These control everything outside the terminal: the titlebar, panels, statusbar, borders, and hover states.
These six variables cascade through the entire UI. alone changes buttons, active states, badges, gauges, and highlighted text across every panel.
— Effect Toggles (author-defined)
This is where it gets interesting. Unlike the terminal and chrome variables, effect variables are defined by the skin author, not by the shell. The Effects panel in the desktop app discovers them automatically by scanning for any declaration.
The panel renders a toggle + intensity slider for each one. The range is 0 to 2:
- 0 = Off
- 1 = Author's intended default
- 2 = Max boost (200%)
The skin author gates their visual effects using these variables:
When the user drags the Glow slider to 0, the box-shadow blur becomes 0px. When they push it to 2, it becomes 36px. The skin author designs for 1 (default), and users customize from there.
Why This Works
The contract creates a clean separation:
- Skin authors own the aesthetics. They decide what the skin looks like, what effects it has, and what the defaults are.
- Users own the controls. They can adjust any effect, swap any color override, and save custom presets — all without editing CSS.
- The shell owns the interaction. Clicks, hovers, permission dialogs, and accessibility features are protected by preflight rules that run after the skin loads.
This means a skin author can go completely wild — animated backgrounds, reactive glows, CSS art, grid overlays, CRT distortion — and the user always has a way to dial it back or turn it off.
The Validator
Every skin uploaded to the community marketplace goes through a validator that checks for effects not gated behind variables. If you use without gating it, the validator catches it and generates a one-click fix prompt you can paste into any AI assistant.
The validator checks six effect families: motion, glow, frost, overlay, distortion, and color shift. It also catches "dead toggles" — variables declared in that no rule actually reads. Every warning is actionable. Nothing blocks your upload, but the warnings show up on your skin's listing page so downloaders know what to expect.
Custom Variables
Beyond the contract, skin authors can define their own variables using the prefix:
These are purely for the skin's internal use — the shell doesn't read them, but they let skin authors avoid repeating magic numbers.
The Beauty of Constraints
The CSS variable contract is deliberately constrained. Twenty-one terminal colors. Six chrome colors. Author-defined effects. No JavaScript. No . No external URLs. These constraints make skins safe, portable, and composable — and they make the community possible. Anyone can write a skin, anyone can review a skin, and every skin works the same way.
If you want to try building one, the skinning guide has everything. Start with the contract, add your personality, and ship.