Variable-first Architecture
Traditional utility engines map a class name to a static value, text-blue-500 → #3b82f6. Maple maps a class name to a semantic fallback chain of CSS variables.
When you write a utility like c-primary-500, Maple generates a CSS rule that progressively searches for meaning at multiple levels:
.c-primary-500 {
color: oklch(
from
/* 1. Is there a specific override for color property? */
var( --c-primary,
/* 2. Is there a generic 'color-primary'? */
var(--color-primary,
/* 3. Is there a global 'primary' token? */
var(--primary,
/* 4. Fallback */
primary
)
)
)
/* ... plus lightness, chroma, and hue modifiers */
);
} The same principle applies to every utility, not just colors. A spacing utility like pb-2 resolves to:
.pb-2 {
/* 1. Is there a specific override for padding-bottom property? */
padding-bottom: var(--pb-2,
/* 2. Is there a generic spacing token? */
var(--space-2,
/* 3. Fallback */
calc(2rem * var(--pb-spacer, var(--p-spacer, var(--spacer, 0.25))))
)
);
} Direct Assignment
When you want to bypass the variable system, you can use = to inject a literal value directly:
<div class="w=86% c=#ff0000"></div> Local Scoping
You can define variables directly in the HTML using class syntax, allowing theming of component instances without writing custom CSS:
<div class="--primary=blue brc-primary-500 c-primary-700">I am blue.</div>What this architecture enables
By leaning on the browser's native cascade rather than hardcoded compiler outputs, Maple unlocks massive flexibility:
- Component-scoped theming: Change the look of a specific UI card without affecting the global primary color.
- Portable components: Copy and paste HTML that automatically adapts to the host environment's variables.
- Runtime design tokens: Update your entire application's theme instantly via JavaScript without generating new CSS.
- CMS-driven styling: Allow content editors to define dynamic layouts and colors safely.