fuz_css is a semantic-first CSS framework and design system. Semantic HTML looks finished with zero classes: headings, links, buttons, forms, tables, and callouts come styled, and block elements space themselves. Themes are a handful of knobs, not a stylesheet: hues, intents, lightness curves, and scales re-derive every color and size in plain CSS, and the contrast, gamut, and ramp-order checks the shipped themes pass are an API for checking your own. See the themes and try the editor.

The Vite plugin generates one stylesheet with the theme variables, base styles, and utility classes your code uses, for Svelte, React, Preact, Solid, and plain HTML. Without a build step, link the package's two plain stylesheets. For companion Svelte components see fuz_ui.

More at the docs and repo.

The Vite plugin is the recommended setup. It generates one stylesheet holding the theme variables, the base styles for the elements you use, and the utility classes you use, and it updates with HMR as you edit. It works with SvelteKit, Svelte, React, Preact, Solid, and plain HTML/TS/JS. Without a build step, link the package's two plain stylesheets instead.

Working setups for each framework live in the repo's examples.

Import the virtual module once, from the root layout:

JSX needs a parser plugin, which you install yourself: acorn-jsx, passed through the acorn_plugins option.

Preact is the same with @preact/preset-vite. For Solid, list the fuz_css plugin before solid(), as the Solid example does:

Then import the virtual module in your entry file:

Supported JSX patterns:

• className="..." and class="..." - static strings
• className={clsx(...)} - utility function calls
• className={cond ? "a" : "b"} - ternary and logical expressions
• classList={{active: cond}} - Solid's classList
• usage tracking: variables in className, class, and classList are tracked back to their definitions, within one file

The acorn_plugins option accepts any Acorn-compatible plugin, so other syntax extensions can be supported the same way.

Svelte and plain HTML/TS/JS need no parser plugin. With the Svelte plugin outside SvelteKit, list the fuz_css plugin first, as the Svelte example does:

The package ships two plain stylesheets, the base style.css and theme.css with every variable, which work in any page, and jsDelivr serves them from npm:

That's the full semantic styling and every style variable, including the builtin classes like selected and palette_a. Utility classes need the plugin, since they're generated from your source, and so does baking a theme in; without it, write the variables into your own CSS. Pin a version in the URL so a release can't change your page.

Declare the virtual module once, in a dedicated declaration file like src/fuz_css.d.ts (not a SvelteKit app.d.ts, which is a module):

The virtual:fuz.css import alone is all most projects need. Projects managing their own theme or base styles can turn the generated ones off and import the full stylesheets, so neither layer ships twice:

Every rem length on the page is measured against that root, including ones that come from elsewhere: a third-party component sized for a 16px rem renders at 62.5% of what its author intended. Size your own lengths with the style variables, and check any rem-based CSS you bring in. A @media query is the exception, since its rem is the browser's initial font size: the sm: breakpoint's 40rem is 640px.

Coming from Tailwind, whose spacing scale assumes a 16px rem (p-4 is 1rem, 16px): here 16px is 1.6rem, and the spacing tokens like p_lg carry the scale, so pasted Tailwind lengths come out smaller.

The plugin needs Vite 6 or later. It extracts classes from files as Vite processes them, including from node_modules dependencies, and in dev it pre-scans your sources and the root index.html at startup so the first page load is fully styled. List it after any plugin that rewrites CSS in its transform hook.

• acorn_plugins - required for JSX frameworks, e.g. acorn-jsx
• additional_classes - classes to always include (for dynamic patterns that can't be statically extracted)
• exclude_classes - classes to exclude from output
• class_definitions - custom class definitions to merge with defaults; can define new classes or override existing ones (see composite classes). A callback receives the defaults and returns the whole set, so () => my_definitions uses only your own
• class_interpreters - custom interpreters for dynamic class generation; an array replaces the default interpreters, and a callback receives them and returns the ones to use (most users don't need this)
• filter_file - custom filter for which files to process. Receives (id: string, root: string) and returns boolean, e.g. (id) => !id.includes('/fixtures/')
• on_error - 'log' or 'throw'; defaults to 'throw' in CI (CI set to anything but empty, false, or 0), 'log' otherwise
• on_warning - 'log', 'throw', or 'ignore'; defaults to 'log'
• cache_dir - cache location; defaults to .fuz/cache/css
• cache_salt - a string folded into the cache key; change it when only an acorn plugin's options change, since the key already covers file content, the plugins, and the installed versions of fuz_css and its parsers
• prescan - dev-only scan of sources at server startup; true (default) scans src under the Vite root, false disables, or pass an array of directories
• base_css - customize or disable base styles; set to null for utility-only mode, or provide a string to replace the defaults or a callback to modify them (see what gets included)
• variables - customize or disable theme variables; set to null for utility-only mode, or provide an array to replace the defaults or a callback to modify them
• theme - a theme to bake into the generated CSS, overlaid onto variables last-wins by name
• additional_elements - elements to always include styles for (for runtime-created elements), or 'all' to include all base styles
• additional_variables - variables to always include in theme output, or 'all' to include all theme variables

The stylesheets work with any framework and plain HTML. The utility class generator's detection support varies by framework:

The additional_classes option is an escape hatch for classes that can't be statically detected. Angular and Vue's single-file components aren't supported; we could revisit this if there's demand.

Browse the full api docs.

fuz_css styles HTML elements in its reset stylesheet, so semantic markup gets themed and color-scheme-aware styling automatically - utility classes optional. The goal is to be accessible and attractive out of the box, minimal yet extensible.

All opinionated styles live in the fuz.base cascade layer, so your unlayered styles and the generated utility classes override them by layer order alone. Their selectors are also wrapped in :where() for zero specificity, so overrides stay easy even inside the fuz layers. The exceptions are the document-wide rules: :root, body, [hidden], and ::selection.

Add the .unstyled builtin class to opt out of decorative styling while keeping reset normalizations. Works for both decorative containers and interactive elements like links, buttons, inputs, and summary.

styled link vs unstyled link

styled button unstyled button

Block elements get margin-bottom via :not(:last-child), creating natural vertical rhythm without trailing margins.

The --flow_margin variable is unset by default, falling back to var(--space_lg). Size composite classes like .sized_sm and .sized_lg set --flow_margin to adjust vertical rhythm for all flow elements and headings.

Headings add a top margin too, a larger multiple of --flow_margin. A heading that opens a padded or bordered box - .panel, .pane, aside, blockquote, fieldset, dialog, li, td, or th - drops it, so it sits on the box's padding instead of stacking a gap on it.

For elements not in the flow list, use the .mb_flow and .mt_flow composite classes to get the same size-responsive spacing. Use .mb_lg when you want a fixed value that ignores size composites.

The .row layout composite resets margins on its direct children. Flow margins make less sense in horizontal flex layout - for spacing prefer gap utilities like .gap_md and gap: var(--space_sm) instead.

Links and form controls show focus as an outline ring, and only the ring - focus adds no fill. The ring follows :focus-visible, so keyboard focus and a click into a text field or select show it, while a mouse click on a link, button, or checkbox doesn't leave it behind.

The base styles read ARIA state attributes on the elements they apply to:

• aria-pressed="true" on a button, or on any .selectable or .menuitem, takes the .selected look, and stays clickable like .deselectable
• aria-current on a link (any value but false) takes the selected link look
• aria-disabled="true" on a button or form control takes the disabled look with no hover or active states, but keeps its focus ring and pointer events, so it stays reachable by keyboard and can explain why it's disabled; on a .deselectable .menuitem or .selectable, it drops the pointer cursor
• aria-invalid="true" on an input, textarea, or select turns its border and focus ring negative

Under forced colors (Windows High Contrast), the states painted only by a background are restated in system colors: a checked radio, a range, and the edges of .panel and .pane in the text color, and selection - selected and pressed buttons, .menuitem, .selectable - as a Highlight border and inner band that becomes a double Highlight ring when focused, while a focus ring alone stays the text color. Labels keep the system's colors, and so do icons drawn in currentColor. Selects get their native arrow back.

See the related docs for specifics:

• buttons - button states, colors, variants
• elements - links, lists, tables, code, details
• forms - inputs, labels, checkboxes, selects
• typography - headings, fonts, text styles

A theme is a set of knob values, not a stylesheet: plain data naming variables, where a handful of high-leverage knobs (hue angles, chroma_scale, the lightness curves - see colors) reshape everything derived from them. Selecting a theme applies it to this whole website and loads its knobs into the editor below.

Contrast is a modifier, not a theme: the low and high contrast modifiers compose over any theme with compose_themes (flatten + last-wins), so every theme gets both variants for free. The OS prefers-contrast: more preference maps onto the same variables the high contrast modifier sets, so it reaches every theme with no modifier picked.

Light and dark are color schemes within a theme ( color-scheme), not separate themes: each variable carries a base value that applies in both and an optional dark value that replaces it in dark mode, so any theme can implement dark mode. The scheme follows prefers-color-scheme by default. To set it manually, add the dark or light class to the root html element, or use a component like ColorSchemeInput (the picker at the top of this page) from the companion Svelte library fuz_ui.

A theme can instead take a single-scheme stance with scheme: 'light' | 'dark': its one appearance renders in both color schemes, and color-scheme is pinned to match. The phosphor and marquee themes are dark-only this way, since a CRT and a lit sign have no daytime appearance. Every other theme is dual-scheme, parchment included, whose dark appearance is the same page by candlelight.

A stanced theme stays plain data. What the stance implies, the scheme-adaptive defaults re-slotted into its one appearance, is computed where the theme renders rather than stored in it, so a saved theme never carries a stale copy: resolve_theme_stance(theme) in theme_stance.ts returns the theme with its scheme_mirror beside it, ready for render_theme_style(resolved.theme, resolved).

A theme applies at build time or at runtime, and most projects want build time. Every theme on this page ships as its own module under themes/, and themes.ts holds the registry and the contrast modifiers.

Pass a theme to the Vite plugin and its values bake into the generated CSS - no runtime rendering, no JavaScript shipped, and the output stays tree-shaken:

The theme's variables replace the defaults by name, so it composes with the variables option, and a stance mirrors the configured variables. They also render into the fuz.theme.baked cascade layer, above the OS preference mappings and with color-scheme pinned for a stance, so a baked theme behaves the same as one applied at runtime.

For runtime switching - a picker, or a theme loaded per user - use ThemeRoot from fuz_ui, which renders the theme to a <style> element in the fuz.theme layer. The two paths compose: a runtime theme overrides a baked one, since a layer's direct styles outrank its sublayers. Outside Svelte, render_theme_style in theme.ts does the same rendering for any framework.

Knobs take effect at the root: the derived color stops compute on :root and descendants inherit the result, so setting a knob like --chroma_scale on an element changes nothing below it. Set knobs through a theme, and when a subtree needs its own color, set the variable its styles read there instead.

Drag a knob and the whole page rethemes live. Extreme values can make the page hard to read, which is an honest signal, not a bug. Every edit updates a temporary "unsaved" theme in the picker above; it survives navigating away and back, but copy the Theme object from the output below to keep it.

validate_theme(theme) in theme_validate.ts is the structural lint. Unknown variable names are errors, and everything else it flags is an advisory warning: type and range mismatches on the knob-tier variables, a dark slot under a single-scheme stance, and intent bindings that put the accent beside a status hue or drop a palette slot's chroma character. It returns an array of issues - empty means the theme is structurally sound.

check_theme(theme) in theme_check.ts runs the gamut, ramp-monotonicity, and contrast gates against the theme's resolved values. It reports rather than throws, returning {ok, entries, unchecked}. The contrast gates measure the pairings the default styles make on the page background - body and subtle text, links, borders, fills, and colored labels, including a .palette_a button's label on its own tinted fill at rest, hovered, and pressed. They follow the role variables those styles paint through, so a theme that sets border_color to var(--text_60) has its borders measured at text_60, in an entry named border_color vs shade_00.

A value a gate depends on but can't evaluate lands in unchecked instead of passing unread: a knob that doesn't resolve to a number, or a color stop or role set to anything other than an oklch(L C H) numeric literal or an exact var() reference to another gated color. ok is true only when every entry passes and nothing is unchecked, which suits a CI or test assertion:

compile_theme(theme) in theme_compile.ts is for themes that move hues or palette lightness - monochrome, rotated, or dark-only. It recomputes the per-stop sRGB gamut caps from the theme's actual hues and the lightness each stop resolves to, returning the corrected _palette_chroma_NN caps beside the theme rather than in it: {theme, scheme_mirror, caps, report, issues}, which renders as render_theme_style(compiled.theme, compiled). The theme comes back untouched, so compiling again gives the same caps. Chroma pushed past the caps on purpose (chroma_scale above 1) still clips afterward, and the report says so. A theme baked in at build time gets its caps recomputed automatically, with its gate failures reported as build warnings and its validate_theme issues as build errors and warnings.

fuz_css gates its own themes with these functions in its test suite, every theme × contrast-modifier composition included, and declares what an exemplar knowingly gives up, like marquee's clipped gamut, as exact exceptions. The editor above runs the same lint and gates live on every edit.

Style variables, or just "variables" in fuz_css, are CSS custom properties that can be grouped into a theme. Each variable has a base value that applies in both color-schemes, a dark value that replaces it in dark mode, or both. They're design tokens with an API.

The goal of the variables system is to provide runtime theming that's efficient and ergonomic for both developers and end-users. Variables can be composed in multiple ways:

• by CSS classes, both utility and component
• by other variables, both in calculations and to add useful semantics (e.g. button_fill_hover uses shade_50 but can be themed independently)
• in JS like the Svelte components in fuz_ui

Variables also provide an interface that's generally secure for user-generated content, if you're into that kind of thing.

The result is a flexible system that aligns with modern CSS to deliver high-capability UX and DX with low overhead.

Most color variables are derived: knobs feed ramp stops and ramp stops feed color stops, all computed in pure CSS (calc()/pow()/oklch()). Scale knobs like radius_scale derive other families the same way, and a derived token or color stop can still be pinned as an escape hatch. The ramp stops in between are internal (--_palette_lightness_30), so a theme can't set them. See themes for setting the rest.

In bundled mode, only the variables your code uses are emitted, along with any they depend on. The full theme.css stylesheet ships every variable, for utility-only mode and direct imports.

Both are @fuzdev/fuz_schema schemas, so the same names validate at runtime: s.parse(Theme, value) reports what's wrong, parse_theme(value) returns a theme or null, and validate_theme(theme) in theme_validate.ts runs the full lint.

Hooks are the contextual surface: custom properties the base styles and classes read but don't declare as variables, so they have no :root default. Set one on an element to retune what reads it there, with a literal class like --flow_margin:0 or in a component's styles - the sized_* composites work this way, setting --flow_margin and --font_size for their subtree. Where nothing sets a hook, its read falls back to the value listed. A local hook is declared by the rule that reads it, so a value reaches it only from a rule on the same element.

Hooks aren't theme variables: from a theme's root, an inherited hook retunes every element that reads it and a local one reaches nothing, so validate_theme warns on a theme that sets one. Themes turn the knobs instead. The catalog is style_hooks.ts.

The extractor scans your source files and extracts class names using three automatic mechanisms, plus manual hints for edge cases:

1. Direct extraction from class attributes

String literals and expressions in class contexts are extracted directly:

• class="..." - static strings
• class={[...]} - array syntax (for clsx-compatible frameworks like Svelte)
• class={{...}} - object syntax (for clsx-compatible frameworks like Svelte)
• class={cond ? 'a' : 'b'} - ternary expressions
• class={(cond && 'a') || 'b'} - logical expressions
• class:name - class directives (Svelte)
• clsx(), cn(), cx(), classNames() - utility function calls

2. Naming convention

Variables ending with class, classes, className, classNames, class_name, or class_names (case-insensitive) are always extracted, regardless of where they're used:

3. Usage tracking

Variables used in class attributes are tracked back to their definitions, even if they don't follow the naming convention:

Usage tracking works for variables inside clsx(), arrays, ternaries, and logical expressions within class attributes. Note that standalone clsx() calls outside class attributes don't trigger tracking - use the naming convention for those cases.

4. Manual hints

For dynamically constructed classes that can't be statically analyzed, use the @fuz-classes comment:

A common case is iterating over variant arrays to generate demos or UI. The extractor sees class="shadow_alpha_{variant}" but can't resolve what variant will be at runtime:

Alternatively, use the additional_classes option in your Vite plugin config:

Use exclude_classes to filter out false positives from extraction. This also suppresses warnings for these classes, even if they were explicitly annotated:

Element hints

Similar to @fuz-classes, use @fuz-elements to declare elements that should be included even when they can't be statically detected:

CSS variable detection

CSS variables are detected via simple regex scan of var(--name patterns in all source files. Only theme variables are included; unknown variables are silently ignored. This approach catches usage in component props like size="var(--icon_size_xs)" that AST-based extraction would miss.

When variable names are constructed at runtime (e.g. with template literals), use @fuz-variables to explicitly include them:

5. Build-time limitations

Class and element detection happens at build time via static analysis. Content created dynamically at runtime (document.createElement(), innerHTML, framework hydration) won't be detected.

Use additional_elements to force-include element styles for runtime-created elements:

Detection finds the classes, elements, and variables your source uses (see class detection above), and resolution turns that into CSS. Bundled mode (the Vite plugin's default) combines three layers into a single output, each trimmed to what your code uses:

1. style variables as :root custom properties (the full version of which is theme.css)
2. the reset stylesheet's base styles for the HTML elements you use (the full version of which is style.css)
3. used utility classes (always generated on demand; there's no full version)

Sections are emitted in that order inside @layer cascade layers: defaults in fuz.base, OS user-preference mappings (like prefers-contrast) in fuz.preferences, theme overrides in fuz.theme, and utilities in fuz.utilities, so utilities beat the reset by layer order (not specificity) and your own unlayered styles beat everything. The exceptions are two !important declarations, which a layer makes outrank unlayered styles too: [hidden], and the prefers-reduced-motion mapping that clears the --duration_* variables so a theme can't re-enable motion.

If you use @layer for your own styles, declare fuz's layers first so yours come later and win: @layer fuz.base, fuz.preferences, fuz.theme, fuz.utilities, app;. Without that line, fuz's layers are declared when its CSS loads, after any of yours, and beat them.

Inside fuz.utilities, composites (box, panel, sized_md, and the other multi-property ones) render in a fuz.utilities.composites sublayer - the single-property shortcuts like circular and mb_flow order with the token classes - so a token or literal class always wins over a composite it overlaps: panel shadow_md gets the medium shadow, at every breakpoint. Within each, the order comes from what the classes mean, not their names (two literals of one property still conflict by name): unmodified classes first, then media queries - min-width breakpoints ascending, max-width ones descending, then feature queries like print: - then color-scheme classes, and within those, shorthands before longhands (p_md before pl_lg) and states in link-visited-focus-hover-active order. So p_sm md:p_md lg:p_lg steps up as the viewport widens, however the classes are written.

Base styles

A rule from the reset stylesheet is kept when any element or class in its selector is detected. Kept rules are emitted in source order, tree-shaking unused rules. A top-level @media, @supports, or @container rule is kept or dropped whole, by the elements and classes of the rules inside it.

Some rules are always included regardless of detection:

• the universal reset (*), :root and :host, html, and body
• rules whose selector can't be matched against what's detected: one naming no element or class (like ::selection and [hidden]), or an escaped or non-ASCII name (like .md\:flex)
• every other at-rule, like @keyframes and @font-face

For apps that use dynamic HTML patterns, element detection may have false negatives, omitting styles that you actually need. The reliable fix is to ship the full reset with additional_elements: 'all'. Reach for an explicit additional_elements list only when you want to keep the base CSS minimal and know exactly which extra tags appear at runtime.

The base_css option replaces the reset stylesheet with a string, or transforms it with a callback that receives the default CSS. Either form takes any CSS the parser accepts and is tree-shaken by the rules above. All of it lands in fuz.base, a callback's additions included, so it sits below themes and utilities; put overrides that must win in your own stylesheet.

The generator owns the layering, so an @layer of your own in base_css is an error (base_css_layer), as are @import and @namespace, which are invalid inside a layer (base_css_unsupported_at_rule). An error never removes CSS: the rule ships as written, and the error names it and its line. Only a top-level @charset is left out, since an encoding marker means nothing in a string.

Variables

A style variable is included when:

• a kept base-style rule uses it,
• a generated utility class uses it,
• your source references var(--name) directly, e.g. in a style attribute, a <style> block, or an imported CSS file (including a dependency's stylesheet), or
• it's force-included via additional_variables.

Dependencies resolve transitively, so pulling in a variable also pulls in any it's built from via var(), and both light and dark values are kept together, so switching color-scheme at runtime never hits a missing variable. The complete set ships in theme.css for utility-only mode and direct imports; bundled mode trims it to what you use.

The variables option is the whole set to draw from. If a kept base-style rule references a variable the defaults define but your set lacks (with null, an empty array, or a partial set), generation reports the error undefined_theme_variables, since a var(--name) with no fallback would resolve to nothing. It never fires for a reference with a fallback, a name the base styles declare themselves (in the same rule, or in a top-level rule whose selector is exactly :root, :host, html, body, or *), or a custom property of your own.

Define the missing variables, or for bundled base styles over a theme stylesheet you import separately, declare the default set defined elsewhere:

Forcing and excluding

When static analysis can't see something, or sees too much, override resolution with the CssGeneratorBaseOptions: additional_classes, additional_elements, and additional_variables force-include (the element and variable options also accept 'all'), while exclude_classes, exclude_elements, and exclude_variables drop items from the output. Excluding a variable that's still referenced by included styles logs a warning, since the dropped var(--name) would otherwise resolve to nothing.

Modifiers prefix any class type (token, keyword, composite, or literal) to apply styles conditionally based on viewport, state, or color scheme. This is what makes utility classes more powerful than inline styles.

Responsive modifiers

Mobile-first breakpoints:

State modifiers

Pseudo-class modifiers for interaction and form states:

Available state modifiers include:

• interaction: hover: focus: focus-visible: focus-within: active: link: visited: any-link: target:
• form: autofill: blank: disabled: enabled: checked: indeterminate: required: optional: valid: invalid: user-valid: user-invalid: in-range: out-of-range: placeholder-shown: read-only: read-write: default:
• structural: first: last: only: first-of-type: last-of-type: only-of-type: odd: even: empty: nth-child(N): nth-last-child(N): nth-of-type(N): nth-last-of-type(N):
• UI states: fullscreen: modal: open: popover-open:
• media: playing: paused:

Color-scheme modifiers

Apply styles in dark or light mode:

dark: and light: apply when the root element has the dark or light class (fuz_ui's theme state sets one), and when it has neither they follow the OS prefers-color-scheme, so they work without JS. They add no specificity (the root selector is wrapped in :where()), so a hover: class still wins while hovering in dark mode.

Pseudo-element modifiers

Style generated content and element parts:

available: before: after: cue: first-letter: first-line: placeholder: selection: marker: file: backdrop:

Media feature modifiers

Accessibility and context-aware styles:

available: print: motion-safe: motion-reduce: contrast-more: contrast-less: portrait: landscape: forced-colors:

fuz_css's main stylesheet provides styles for base HTML elements using style variables, acting as a modern CSS reset that adapts to dark mode. It includes CSS classes that provide common generic functionality - these are called builtin classes.

.unstyled

Default list (styled):

• 1
• 2

With .unstyled:

• a
• b

The .unstyled class lets fuz_css provide solid default element styles with a simple opt-out:

This strategy supports semantic hooks for theming:

See the specific docs sections for more about .unstyled.

Other builtin classes

• .selected - see buttons, forms
• .disabled - see forms
• .deselectable - see buttons
• .inline - see buttons, forms
• .heading - see typography
• .title - see forms
• .row - see layout, forms
• .palette_a through .palette_j - see buttons, colors
• .dark, .light on :root - see themes

Interpreters dynamically generate CSS for class names that aren't in the static definitions (which can be extended via class_definitions, or replaced with a callback that ignores the defaults). The default CSS-literal syntax is implemented as an interpreter, which you can extend or replace. Modifiers aren't - the generator strips them from every class name before resolving it, so they apply to interpreted classes too.

For advanced use cases, you can define custom interpreters that generate CSS from arbitrary class name patterns. This is similar to UnoCSS's dynamic rules, which also use regex + function patterns. An interpreter has a regex pattern and an interpret function that returns a definition shaped like a static one - a declaration, a ruleset, or composes - or null to pass:

This generates grid-cols-1 through grid-cols-24 on-demand, something that would require 24 separate composite definitions, and md:grid-cols-4 works with no extra code. Return composite: true alongside a multi-property declaration to render it in the composites sublayer. Note the classes for this example could also be created as composites with a helper function - fuz_css uses this strategy internally to create its token classes in css_class_definitions.ts.

Register with the Vite plugin:

The interpreter context provides access to class_definitions, css_properties (for validation), and diagnostics (for errors/warnings). This enables full programmatic control over class-to-CSS generation.

TailwindCSS and UnoCSS are utility-first frameworks where classes have primacy. fuz_css is semantic-first: utilities complement HTML defaults rather than being the primary styling mechanism.

Where TailwindCSS names a class after the CSS keyword, the keyword classes match it: a TailwindCSS project's flex, hidden, or sticky resolves to the same CSS. Its own names don't, and generate nothing without a warning, so flex items-center justify-between gets display: flex alone - the fuz_css spelling is flex align-items:center justify-content:space-between.

fuz_css's modifier system is less expressive than TailwindCSS's variants. Missing: parent/sibling/descendant state (group-hover:, peer-invalid:, has-checked:), arbitrary variants ([&.is-dragging]:), child selectors (*:), container queries (@md:), data/ARIA variants, and more. When you need these patterns, fuz_css currently expects you to use rulesets or <style> tags, but the API is still a work in progress, and a more powerful and potentially more TailwindCSS-aligned system is on the table.

For extensibility, all three frameworks allow custom class-to-CSS mappings. UnoCSS's dynamic rules use regex + function patterns similar to fuz_css interpreters, plus separate variants for modifiers. TailwindCSS uses JS plugins and UnoCSS has the more mature extensibility story; fuz_css offers comparable power with interpreters but it's still evolving - feedback is welcome!

fuz_css fits best when you prefer semantic HTML with styled defaults. Design tokens are defined in TypeScript, naturally adapt to dark mode, and can be imported in TS for typesafe runtime access. The tradeoffs include a more limited DSL and more verbose literal syntax, which nudges you toward <style> tags, tokens when appropriate, or composites for repeated patterns.

fuz_css is still early in development. Your input and feedback is appreciated in the GitHub issues for bugs and discussions for everything else.

fuz_css's colors are derived: a handful of high-leverage knobs produce every color variables in pure CSS, in the oklch colorspace, adapting to the color-scheme automatically. OKLCH lightness is perceptually uniform (equal lightness reads equally light in every hue), so rotating a hue knob is safe: contrast and visual weight hold.

Hues use letters so themes can reassign colors without breaking semantics ("a" is blue by default but could be any color). Meaning attaches through the intent knobs layered on top: --hue_accent (links, focus, selection, selected states - what other systems call "primary") defaults to --hue_a, --hue_negative to --hue_c, and so on. Retarget an intent to move just that meaning; rotate a letter to move the palette.

Hue variables contain a single OKLCH hue angle. Because lightness and chroma are shared across all hues at each stop, the scales are interchangeable: setting a hue alone is enough, no per-hue tuning required. The one deliberate exception is the per-slot chroma multiplier - the brown slot ships muted because no hue angle renders brown at full palette chroma.

Hue variables are also useful to construct custom colors not covered by the palette. For example, fuz_css's selection color derives from --hue_accent (try selecting some text - same hue!).

Hue variables are the same in both light and dark modes (non-adaptive).

• hue_a

  250

  blue · default accent
• hue_b

  144

  green · default positive
• hue_c

  29

  red · default negative
• hue_d

  296

  purple
• hue_e

  98

  yellow
• hue_f

  60

  brown · default neutral
• hue_g

  358

  pink
• hue_h

  41

  orange · default caution
• hue_i

  210

  cyan · default info
• hue_j

  180

  teal

Each hue has intensity variants from subtle to bold (00, 05, 10, 20, ..., 80, 90, 95, 100), with 50 at the middle of the ramp. The 60 variant is the text-safe stop: links, the labels of chips, and a selected .palette_X button's fill use it. .palette_X buttons label at 70, one step further, since their own tint deepens behind the label as it's hovered and pressed. check_theme gates all of these pairings at AA.

Palette variables work for both text and backgrounds through utility classes: .color_a_50 sets the text color and .bg_a_50 the background, and the intent scales below do the same. The shade and text scales are split by role instead, one for surfaces and one for text.

Palette stops are adaptive: they switch between light and dark ramps based on color scheme. There are no absolute variants; for a color that doesn't adapt, write the literal color or define one custom property.

• palette_a_00
• palette_a_05
• palette_a_10
• palette_a_20
• palette_a_30
• palette_a_40
• palette_a_50
• palette_a_60
• palette_a_70
• palette_a_80
• palette_a_90
• palette_a_95
• palette_a_100
• palette_b_00
• palette_b_05
• palette_b_10
• palette_b_20
• palette_b_30
• palette_b_40
• palette_b_50
• palette_b_60
• palette_b_70
• palette_b_80
• palette_b_90
• palette_b_95
• palette_b_100
• palette_c_00
• palette_c_05
• palette_c_10
• palette_c_20
• palette_c_30
• palette_c_40
• palette_c_50
• palette_c_60
• palette_c_70
• palette_c_80
• palette_c_90
• palette_c_95
• palette_c_100
• palette_d_00
• palette_d_05
• palette_d_10
• palette_d_20
• palette_d_30
• palette_d_40
• palette_d_50
• palette_d_60
• palette_d_70
• palette_d_80
• palette_d_90
• palette_d_95
• palette_d_100
• palette_e_00
• palette_e_05
• palette_e_10
• palette_e_20
• palette_e_30
• palette_e_40
• palette_e_50
• palette_e_60
• palette_e_70
• palette_e_80
• palette_e_90
• palette_e_95
• palette_e_100
• palette_f_00
• palette_f_05
• palette_f_10
• palette_f_20
• palette_f_30
• palette_f_40
• palette_f_50
• palette_f_60
• palette_f_70
• palette_f_80
• palette_f_90
• palette_f_95
• palette_f_100
• palette_g_00
• palette_g_05
• palette_g_10
• palette_g_20
• palette_g_30
• palette_g_40
• palette_g_50
• palette_g_60
• palette_g_70
• palette_g_80
• palette_g_90
• palette_g_95
• palette_g_100
• palette_h_00
• palette_h_05
• palette_h_10
• palette_h_20
• palette_h_30
• palette_h_40
• palette_h_50
• palette_h_60
• palette_h_70
• palette_h_80
• palette_h_90
• palette_h_95
• palette_h_100
• palette_i_00
• palette_i_05
• palette_i_10
• palette_i_20
• palette_i_30
• palette_i_40
• palette_i_50
• palette_i_60
• palette_i_70
• palette_i_80
• palette_i_90
• palette_i_95
• palette_i_100
• palette_j_00
• palette_j_05
• palette_j_10
• palette_j_20
• palette_j_30
• palette_j_40
• palette_j_50
• palette_j_60
• palette_j_70
• palette_j_80
• palette_j_90
• palette_j_95
• palette_j_100

Intent scales name colors by meaning: --accent_NN, --positive_NN, --negative_NN, --caution_NN, and --info_NN, with the palette's stops, derived through the same ramps from each intent's hue knob (--hue_accent and the rest). Each hue binds to a palette letter by default, so an intent scale matches its letter's until a theme rebinds it: accent → a, positive → b, negative → c, caution → h, info → i.

Reach for an intent when the color carries meaning, like an error or a success, and for a letter when it's only a color, so a theme can move the meaning without recoloring every use of the letter. The classes follow the palette's: .positive_50 sets the text color and .bg_positive_50 the background. Border, outline, and shadow classes exist only for the letters, so reach an intent there with a literal like border-color:var(--negative_50).

• accent_00
• accent_05
• accent_10
• accent_20
• accent_30
• accent_40
• accent_50
• accent_60
• accent_70
• accent_80
• accent_90
• accent_95
• accent_100
• positive_00
• positive_05
• positive_10
• positive_20
• positive_30
• positive_40
• positive_50
• positive_60
• positive_70
• positive_80
• positive_90
• positive_95
• positive_100
• negative_00
• negative_05
• negative_10
• negative_20
• negative_30
• negative_40
• negative_50
• negative_60
• negative_70
• negative_80
• negative_90
• negative_95
• negative_100
• caution_00
• caution_05
• caution_10
• caution_20
• caution_30
• caution_40
• caution_50
• caution_60
• caution_70
• caution_80
• caution_90
• caution_95
• caution_100
• info_00
• info_05
• info_10
• info_20
• info_30
• info_40
• info_50
• info_60
• info_70
• info_80
• info_90
• info_95
• info_100

The knobs are the theme API, and the first few carry most themes:

• intent hues - --hue_accent, --hue_positive, --hue_negative, --hue_caution, --hue_info - each pointing a meaning at a palette letter (var(--hue_c)) or a literal angle, and deriving its full stop scale (--accent_00 … --accent_100)
• --hue_neutral + --neutral_chroma - the temperature and strength of every surface, text, border, and shadow tint (the neutral intent, whose scales are the shade and text ramps)
• --chroma_scale - one multiplier from grayscale (0) through calm (1) to vivid (above 1, deliberately clipping the weakest hues)
• lightness ramps - --palette_lightness_00/_100/_curve (and the same trio for shade_ and text_): the endpoint stops plus a curve exponent bending the ramp between them, per color scheme
• chroma curve - --palette_chroma_min/_max and --chroma_curve: a mid-peaked curve, clamped per stop by gamut caps computed from the worst hue
• per-slot chroma multipliers - --palette_a_chroma_scale … --palette_j_chroma_scale and intent twins (--accent_chroma_scale, …), each multiplying one slot's chroma under --chroma_scale. A binding shares only the hue angle, so an intent bound to the muted brown slot needs its twin set too, and validate_theme warns when it isn't
• --hue_a … --hue_j - the palette letters' angles. Rotating one recolors every use of that letter, so registered themes leave them alone and move intents instead

The intermediate values between the knobs and the color stops are internal, spelled with a leading underscore (--_palette_lightness_30, --_palette_chroma_50, …). A theme can't set them - it steers the ramps through these knobs, and can still pin an individual color stop like --palette_a_50.

fuz_css offers a shading model built on adaptive style variables that respond to the color-scheme. Adaptive means the underlying values change between light and dark modes to maintain consistent prominence: low numbers stay subtle, high numbers stay strong. Each theme can implement light mode, dark mode, or both.

Light mode's starting point is plain white documents (like paper) where we subtract light to create contrast and shape. Black shadows on white make natural sense; white glows are near invisible.

Dark mode's starting point is a lightless void where we add light. Elements emit light to fill the darkness. White glows make natural sense; black shadows are near invisible.

The shade scale is the primary system for backgrounds and surfaces. All numbered shades (shade_00 through shade_100) are tinted using the theme's hue_neutral and neutral_chroma for visual cohesion. The scale also includes two untinted extremes (shade_min and shade_max) for maximum contrast needs.

The ink and paper variables provide alpha-based overlays that adapt to the color scheme. Unlike the opaque shade scale, these stack when nested and are used by composites like .panel and .chip.

• --ink_NN (a wash toward the text color) - darkens in light mode, lightens in dark mode; use for elevated surfaces like panels, cards, and hover states
• --paper_NN (a wash toward the ground) - lightens in light mode, darkens in dark mode; use for surfaces that blend toward the background

In light mode, ink is the same as darken and paper is the same as lighten. In dark mode, they're swapped.

The overlays are variables, not token classes, so reach them with a literal class (background-color:var(--ink_10)) or a <style> block. The bg_ classes (.bg_a_50, .bg_positive_50) are opaque.