DEV Community: Andrey Yamanov

Runtime CSS-in-JS deserves a rehearing

Andrey Yamanov — Wed, 07 Oct 2026 12:30:02 +0000

Runtime CSS-in-JS has largely been written off as too expensive for the browser.

The reasons are familiar: some libraries rebuilt styles on every React render, interleaved stylesheet writes with rendering, accumulated generated CSS, and added React overhead to every styled element. Server rendering was awkward, React Server Components seemed incompatible, and build-time CSS appeared to eliminate the entire class of problems.

Those concerns did not come from nowhere. In 2019, Aggelos Arvanitakis described the hidden costs of the CSS-in-JS libraries of the time. In 2022, Emotion maintainer Sam Magura reported in Why We're Breaking Up with CSS-in-JS that replacing Emotion with Sass Modules cut the render time of a large screen almost in half.

The measurements were valid. They answered, “Were these runtime CSS-in-JS implementations expensive?” They left two broader questions open: “Must every runtime-capable styling system pay those costs in the browser?” and “When generation does happen there, does the resulting flexibility justify the cost?”

The same concerns drive more recent migrations. GitHub replaced styled-components with CSS Modules to reduce server and client costs; Linear moved to StyleX for performance and clearer component boundaries; Atlassian adopted Compiled to reduce runtime overhead and support concurrent rendering and streaming SSR.

Those choices strengthen the case for generating known styles early and making styling contracts explicit. Improvements in browsers, React, rendering frameworks, and hardware help, but the stronger reason to revisit the verdict is architectural: style engines can change where they perform work and how often they repeat it. Linear still generates theme rules at runtime, showing how that capability can remain useful within a mostly compiled system. A runtime-capable engine has to justify both the work it leaves in the browser and the freedom it gives consumers to restyle shared components.

People often use runtime CSS-in-JS as shorthand for generating CSS in the browser. Here I separate capability from placement. A runtime-capable system can generate styles wherever its inputs become known: during the build, on the server, or in the browser.

The useful question is not simply whether runtime CSS-in-JS is fast or slow. It is which styling decisions can be made earlier, and whether keeping the rest open justifies the cost. CSS should not always be generated in the browser, but browser generation should remain available when the final composition genuinely remains open.

I will use Tasty, which I created and maintain, as a case study rather than a neutral survey. It is a demanding test: in the browser, Tasty parses values, resolves states and conditions, composes extensions, and generates and injects CSS rather than merely selecting precompiled output. The same components can do that work on a server or during a static build.

My claim is narrow: a runtime-capable system can justify its cost when it controls where and how often that cost is paid and solves composition problems that matter to the product. That does not make every CSS-in-JS library fast or make browser generation free.

Why leave composition open?

A changing value alone is a weak reason to generate CSS at runtime. When the declaration structure is fixed, a CSS custom property is often more direct. Runtime generation becomes useful when some part of the structure—the property set, selector, condition, state, or component extension—remains unknown until the program runs. Open means that the program can introduce a combination that was not enumerated before deployment.

The reason is often ownership: a component and its consumer own different styling decisions. The component owns its appearance and internal layout; the consumer decides how it participates in the surrounding page. A reusable component cannot predict every layout, state, or product-specific extension it will encounter.

In my work at Cube, that boundary became a delivery problem. The component library and the product could not always evolve at the same pace. When a developer needed a styling capability that Cube UI Kit did not expose, the maintainable long-term path was to add a component API first. Product work could not always wait, so developers added local CSS overrides and JavaScript conditions. When the UI Kit eventually gained the capability, those workarounds still had to be found and migrated.

Tasty made those workarounds explicit without making the direct styles prop the preferred API. The preferred fix depends on what is missing. A component can expose individual CSS properties such as width, border, or radius through styleProps. With modProps, it can expose a finite component state or visual variant as a typed prop that selects predefined style branches. New behavior, semantics, and accessibility require dedicated component API props. The direct styles prop remains a poor default and an escape hatch for rare cases that can be justified locally.

When a visual extension remains product-specific, a developer can create a named styled wrapper in the same language as the component library. If the need proves reusable, the wrapper can remain a product-local component or the capability can move into the UI Kit as an exposed style, a state modifier, or a dedicated API. Migration means moving an explicit declaration instead of untangling JavaScript conditions and CSS overrides. Product development and design-system development no longer have to happen in lockstep.

Within that hierarchy, style definitions remain composable one property at a time. Suppose a Button already exposes a loading state modifier and defines fill for its default, hover, and disabled states. A product-local wrapper can add the missing loading branch without copying or replacing that state map:

const LoadingButton = tasty(Button, {
  styles: {
    fill: { loading: '#yellow' },
  },
});

Tasty keeps the existing fill states and adds loading. The product does not have to restate the existing states or create a separate CSS rule that wins through the cascade.

This hierarchy does not prevent exceptions from accumulating; it makes them explicit and movable. Teams still have to decide which should graduate into shared APIs.

The same ownership boundary appears in ordinary layout. Whether a component stretches, aligns itself, fills available space, or sits against an edge is normally decided where it is used. A general-purpose Grid cannot know whether its consumer needs equal columns, a fixed sidebar, named areas, or a template assembled from application data.

A design system can represent those decisions with style props, state modifiers, utilities, custom properties, or wrappers. Restricting the styling surface can be intentional. The tradeoff is that each unpredicted need requires another narrow contract or escape hatch.

Tasty instead acts as a lazy compiler. It receives the concrete styling decision where the component is used and generates the requested CSS. It does not eliminate abstraction; it offers one shared language in place of many APIs that each have to predict their future use.

Runtime capability does not dictate runtime placement

Earlier runtime libraries often connected style generation directly to React rendering. A styled element might run hooks, consume theme context, rebuild a complete class, and insert its rule immediately. Server support then had to reproduce a browser-oriented system in a different environment.

None of those choices is required by CSS-in-JS. A style engine can cache work below the component level, reuse output across components, collect writes until React reaches the insertion phase, and remove rules that are no longer used. React Server Components and build-time rendering also let compatible components produce HTML and CSS without sending their styling runtime to the browser.

The styling language and its execution point are separate architectural decisions.

During the build

When the complete set of styles is known, Tasty can move generation out of the browser in two ways. tastyStatic analyzes application code, writes a CSS file, and leaves class names in the code. A framework that renders pages at build time can instead run regular Tasty components and collect the CSS they produce. Either approach lets a fully static page ship without the Tasty runtime.

On the server

Tasty components can run as React Server Components without adding a 'use client' boundary. On a server-only page, they produce HTML and CSS without sending the Tasty runtime to the browser.

In an interactive server-rendered application, Tasty collects CSS while React renders and can stream it with the page. It also records which classes were generated, so the client can reuse them during hydration instead of generating and injecting them again.

With that handoff, server rendering avoids both a flash of unstyled content and duplicated client work. It requires an implementation designed for the server rather than a client-side injector retrofitted after the fact.

In the browser

Browser generation remains useful when styling values or combinations are still unknown after the build and server render. The browser pays for genuinely new styles, but it can reuse work it has already seen.

These placements are not hypothetical. Cube UI Kit generates styles in the browser; tasty.style does so during React Server Component rendering; tenphi.me does so during Astro's static build. They demonstrate that each placement is viable, not that one always wins.

What static extraction must be able to see

Static tooling can provide the same composition when it can see all the inputs. A closed styling vocabulary can be a deliberate and useful design-system constraint. The tradeoff appears when the product needs a combination outside that vocabulary.

Consider a form renderer that chooses both a component and its extension from a registry:

function Field({ schema }) {
  const { Component, styles } = fieldTypes[schema.type];

  return <Component styles={{ ...styles, ...schema.styles }} />;
}

To reproduce this composition exactly, an extractor has to trace every possible Component back to its original style declaration. It must also find every possible extension and reproduce how each combination merges. That works when fieldTypes is local, finite, and statically visible, and when the schema selects only known entries. The assumption breaks once a package or plugin extends the registry, or application or server configuration supplies additional styles.

Static tooling can accommodate each of those patterns. A team can enumerate variants, safelist output, add compiler annotations, route values through custom properties, or constrain how components are composed. But each accommodation makes source visibility part of the application architecture: every wrapper, registry, package boundary, and data-driven abstraction has to remain legible to the extractor.

Runtime generation is not needed for ordinary static declarations. It is useful when the final combination does not exist until the program runs. At that point, the component and its styles have already met; the engine can combine their concrete values without reconstructing how they traveled through the source.

That visibility requirement extends through the toolchain. The compiler has to participate in every path that handles uncompiled styling code: application builds, unit-test transforms, Storybook, browser-test bundles, separately built component libraries, and sometimes the build of every consuming application. Each path needs compatible compiler and styling configuration.

A library can publish compiled class names and CSS instead, but then it owns CSS delivery. One global stylesheet can force every consumer to load every component's styles. Splitting the output requires the compiler and bundler to agree on which CSS belongs to each module or route, and the generated CSS, JavaScript class names, caches, and package versions must remain in sync.

Static extraction may still be the right choice, but zero browser runtime is not zero system cost. Too often, browser work is quantified while source restrictions, build integration, and CSS delivery remain implicit. These costs are not interchangeable—runtime work is paid by users, while tooling and coordination are paid by teams—but every placement should be judged by the costs it creates and the problems it solves.

The browser costs that remain

When the final styling decision reaches the browser, four areas still matter: generation and reuse, stylesheet writes, stylesheet growth, and React wrapper work.

Generation and reuse

When a Tasty component renders with the same styles, it remembers the class names it produced and skips generation. Dynamic styles are divided into reusable chunks such as layout, dimensions, typography, and appearance. If only padding changes, Tasty reuses the other chunks and generates only the new spacing chunk; another component can reuse that chunk too.

The parser and style pipeline have their own caches, and identical state branches can be collapsed before output is generated. Repeated work stops at the earliest layer that recognizes it. A React render therefore need not trigger another round of parsing, generation, or insertion.

Stylesheet writes and style resolution

Tasty normally keeps generated component rules in one managed <style> element per root, opening another only when the configured limit is reached. The main cost is not creating elements but mutating a live stylesheet. How much work can be grouped depends on when the browser resolves those changes.

Adding a rule marks styles as needing resolution, but the browser does not necessarily recalculate the page at that moment. It can collect several changes and resolve them together when styles are needed. React may split rendering into parts, however, giving the browser several opportunities to resolve styles if stylesheet writes are interleaved with reads.

With batched injection enabled, Tasty's TastyBatchProvider holds new rules while components render. It applies them in React's useInsertionEffect, before layout effects can measure the page. This gives the browser an opportunity to resolve the writes together at a predictable point.

Stylesheet growth

Generated styles can accumulate, especially when every combination of props produces another complete class.

Tasty limits that growth by reusing chunks and deduplicating identical output. During browser idle time, its collector removes old rules that are no longer present on the page after a short grace period. The delay matters because React may generate a class before committing its element; deleting every temporarily absent class could remove a rule during a render.

Unique styles that remain active still grow the stylesheet. Applications with highly dynamic styling should measure that workload. Accumulation does not disappear, but an engine can manage it rather than treating unbounded growth as inevitable.

React wrapper work

Older implementations often made every styled component run hooks or consume theme context. Even a simple element paid that cost whenever React rendered it.

Tasty does not need hooks or React context to generate styles. Cached styles remove the generation work, but the wrapper still processes props and returns the underlying element. That React work remains.

Browser execution also means shipping the Tasty runtime. Its current bundle is substantial because it includes parsing, state and condition handling, composition, injection, and collection. Tasty deliberately prioritizes a rich composition model and predictable execution; reducing download and parse cost remains optimization work. Products that do not need that capability have less reason to pay for it.

Practical cost

Updated September 22, 2026: refreshed the benchmarks and product profile after the optimizations in Tasty 3.9.

Generation, injection, and wrapper overhead are different costs. The useful distinction is between cold and repeated work: new styles pay for generation and injection, while familiar styles take the cached path. The figures below measure those costs separately.

Tasty's latest published benchmarks report three consecutive runs on an Apple M3 Pro, with Node 24.18.0 on AC power for the style pipeline and production React 19.2.8 and Chromium 151 for the browser suites. The earlier figures in this article used an M1 Max and Node 22, so this is an updated snapshot rather than a controlled before-and-after comparison.

Measured work	Time
Render one warmed empty `tasty()` wrapper	~0.5 µs extra per element
Generate a new five-property style	6.3–7.0 µs
Generate a new style with media, hover, and modifier states	28–32 µs
Reuse a cached style	~0.10 µs
Generate, inject, and resolve one new rule	~0.100–0.104 ms extra
Generate and inject 1,000 new rules, then resolve styles once	5.73–5.94 ms extra in total

These figures describe separate paths and should not be added. Generation and cache timings measure the operation directly; wrapper and injection timings are the extra time over matching baselines. The end-to-end injection benchmark already includes generation and subtracts a baseline that performs the same DOM update and style resolution with equivalent CSS already present. React wrapper work is measured separately: the roughly 0.5 µs figure covers mounting/removing or rerendering with unchanged host props; changing a host attribute raises it to 0.86–0.91 µs per element. The full benchmark report publishes the methods, results, and source code.

The pattern matters more than the individual numbers: cached styles avoid most of the work, and grouped writes amortize fixed costs. In these cases, cold generation took a few to a few dozen microseconds, cached reuse took a fraction of a microsecond, and generating, injecting, and resolving a new rule added about a tenth of a millisecond. The 1,000-insertion case added about 55–59 times as much time as the single-rule case, not 1,000 times as much.

Benchmarks isolate the costs; product profiles show whether they matter in context. After the optimizations in Tasty 3.9, Tasty now accounts for roughly 8.3% of main-thread busy time during startup in production Sentry traces from real user sessions on one of Cube's heaviest pages, down from the 12.5% reported here originally. These are observations from ordinary user sessions, not a controlled benchmark or a measure of total page-load time. That share is still material, and whether it is acceptable depends on the product and what the runtime enables.

In latency-sensitive interactions, especially animation-rich UI, creating many previously unseen styles at once deserves scrutiny. That pattern may also reveal a broader workload problem: too much UI mounting in one frame, poor style reuse, or per-frame values expressed as new rules. Precompilation can remove one source of work, but it does not address React, DOM, layout, or paint costs.

Runtime is only half the design

A runtime-capable system still has to express the product's CSS. CSS is more than a dictionary of properties: selectors, conditions, declaration order, overlapping shorthands, and the cascade all carry meaning.

Tasty accepts standard properties and values directly, while its style objects use a small grammar to represent selectors and conditions:

const Card = tasty({
  styles: {
    color: { '': '#text', ':hover': '#accent-text' },
    padding: {
      '': '4x',
      '@media(w < 640px)': '2x',
      '@(sidebar, w < 300px)': '1x',
    },
  },
});

This definition combines a pseudo-class, a viewport condition, and a named container condition. The engine turns them into selectors and at-rules while preserving their declared priority. The same grammar covers features such as :has(), @supports, and CSS structures that do not fit into a flat property object.

Composition needs rules too. CSS properties overlap: padding can reset paddingTop, so naive object merging can change the result. Tasty normalizes related properties into the same style family and resolves that family in a fixed order instead of relying on object insertion order.

This is an opinionated component model, not a replacement for every use of CSS. Tasty does not model features such as @layer or !important, and rules whose intent is genuinely document-wide may be clearer as ordinary CSS. Tasty prioritizes local, explicit ownership; ordinary CSS exposes the full cascade and structural reach. Choosing an execution point does not erase that design tradeoff.

Runtime capability has to earn its place

Runtime-capable styling is one choice in a wider landscape. Teams can use ordinary CSS, preprocessors, utility or variant vocabularies, static extraction, server generation, browser generation, or combinations of them. Each makes different tradeoffs in cascade control, source visibility, tooling, delivery, composition, and browser work. None is right by category alone.

Runtime capability earns its place when final styles depend on information unavailable earlier, or when a narrower component API cannot express a legitimate product need. The rule is to generate CSS as soon as the required styles are known and defer only what remains open:

During the build when every required style becomes known while generating the application, whether through static analysis or build-time rendering.
On the server when the decision is request-specific but complete before the HTML is sent or streamed.
In the browser when values or composition remain open after server rendering, or when making every consumer participate in extraction would cost more than the browser work being removed.

Profile products, not categories. The old evidence described real costs in particular implementations and workloads; it did not settle every use of runtime generation. The relevant question is whether the composition and ownership it enables are worth the cost in your product. If they are not, generate the CSS earlier or choose a simpler approach.

OKHST: predictable color generation for user interfaces

Andrey Yamanov — Wed, 12 Aug 2026 10:27:43 +0000

Wouldn't it be great if one hue slider could recolor an entire interface, while a saturation slider controlled how colorful the whole system felt?

I don't mean a beautiful gradient or a decorative palette. I mean the boring parts of an interface: backgrounds, text, borders, hover states, selected states, disabled states, shadows, dark mode, and high contrast.

The premise sounds simple: pick a hue and saturation, then derive everything else. I chased that idea through several color spaces before finding the assumption that kept breaking it:

lightness is not contrast.

OKHST is the coordinate system I eventually built around that distinction. A CSS playground later in the article tests the model in the browser, while Glaze turns it into a production system.

Originally published on tenphi.me, where the previews are live and the hue slider actually works — here they are screenshots.

The Old Attempt

About seven years ago, I tried to generate UI colors at runtime. Instead of
hand-picking every token, the framework would take a small set of inputs and
derive a complete scheme. HSLuv made the experiment
possible.

HSLuv gave me something regular HSL did not: a perceptually useful lightness
axis. In regular HSL, 50% lightness can mean wildly different things for
yellow, blue, red, and green. HSLuv made "make this lighter" and "make this
darker" much closer to operations a UI system could rely on.

I spent months tuning formulas around it. Eventually, tiny declarations could
color different parts of an interface while the framework kept the palette
consistent. The result was good enough for production, and it was one of the
most fun things I had built at the time.

The old demo is still online: theme.tenphi.me

But the system was coupled to one design system, embedded in our framework, and
tuned for one product. HSLuv was also still immature, so several inconsistencies
needed local workarounds.

The experiment convinced me that UI colors could be computed, but it never
became a reusable tool. I kept using HSLuv, stopped shipping generated
palettes, and waited for a reason to revisit the idea.

The Web Caught Up

That reason arrived with OKLCH in CSS. It gives the web a modern perceptual
color space and makes many color operations more sensible than HSL ever could.
But direct palette generation remains difficult because C is absolute chroma,
not the relative "saturation" control people expect when authoring UI colors.
The maximum possible chroma changes with hue and lightness, so keeping chroma
fixed while changing lightness can push some colors outside sRGB and cause
clipping.

/* Same chroma, different lightness.
   Some hue/lightness combinations may clip in sRGB. */
.step-1 {
  color: oklch(35% 0.18 250);
}
.step-2 {
  color: oklch(65% 0.18 250);
}
.step-3 {
  color: oklch(85% 0.18 250);
}

Manual palettes can work around this: pick each value by eye and adjust the
outliers. Dynamic themes cannot do that so easily. When a background, text
color, border, shadow, and hover state all derive from one source color,
clipping silently changes the relationship between them. A generated ramp can
look fine in the middle and fall apart near the edges.

Modern relative colors make the approach especially tempting:

.card {
  --bg: oklch(65% 0.18 250);

  background: var(--bg);
  color: oklch(from var(--bg) 25% c h);
  border-color: oklch(from var(--bg) calc(l - 0.12) c h);
}

The relationship is elegant, but the same absolute chroma follows the
background into each new lightness value. A generated palette can therefore
drift or clip. What I needed was a saturation axis relative to the maximum
chroma available at each hue and lightness.

OKHSL Gets Saturation Right

OKHSL provides that missing axis. It has the familiar shape of hue, saturation,
and lightness, but builds it on OKLab/OKLCH math. Its saturation is normalized
against what is possible for the current hue and lightness.

Near white and black, where highly saturated colors cannot physically exist in
sRGB, OKHSL desaturates gracefully instead of clipping unpredictably.

This graceful behavior is what a generated UI palette needs.

// Illustrative pseudo-code, not a real library call.
// Same saturation, different lightness — OKHSL keeps it in-gamut.
okhsl({ h: 250, s: 70, l: 20 });
okhsl({ h: 250, s: 70, l: 50 });
okhsl({ h: 250, s: 70, l: 90 });

In OKHSL, 70% saturation means something like:

Use 70% of the chroma available for this hue and lightness.

That is much better for generated UI colors than:

Use this absolute chroma value and hope it still fits.

OKHSL is limited to sRGB, which may sound disappointing in a world of wide-gamut
displays. For core UI, I often find that constraint useful: repeated text,
icons, and borders benefit from a conservative, in-gamut default. Wide-gamut
color still has a natural place in illustrations, decorations, and brand moments.

The Bug in My Mental Model

OKHSL solved the gamut problem, but not the relationship problem. My palettes
still felt wrong in places because I was treating a color's lightness as if it
described its contrast against another color.

Dark mode exposed the mismatch first. Inverting lightness produced a coherent
palette, but the contrast felt weaker than expected, so I added a separate
transformation curve. Then very dark colors in a light scheme also moved
differently from what I expected. The curve had only hidden the underlying
mistake.

// Nice idea, weak invariant:
const dark = { ...light, l: 100 - light.l };

Perceptual lightness describes how light or dark an individual color appears.
UI contrast describes the relationship between two colors, and equal lightness
changes do not produce equal contrast changes across the range.

A simple way to see it is to compare a tiny step near black with the same tiny
step near white.

Near black: l = 0, 1, 2, 3, 4
Near white: l = 96, 97, 98, 99, 100

The numeric movement is the same. The contrast between adjacent steps is not.

Near black, two neighboring steps barely separate. Near white, the same gap
reads as a clear jump.

You can also measure the failure across the whole range. Here is WCAG contrast
for a neutral ramp with equal lightness steps of +20:

Lightness	vs black	vs white	+20 step ×
0	1	21	1.55
20	1.55	14	2.09
40	3.23	6.50	2.05
60	6.64	3.16	1.86
80	12	1.70	1.70
100	21	1	—

The numeric steps are identical, but the contrast multiplier between adjacent
steps drifts from 1.55× up to 2.09× and back down to 1.70×. This variation makes
lightness a poor authoring axis for things like borders, hover states, shadows,
and dark-mode inversion.

I needed an authoring axis where a numeric step described a stable change in UI
contrast. That axis became tone.

OKHST

Tone is a 0-100 authoring axis designed so that equal differences produce
equal contrast multipliers along the neutral axis. A +20 step should describe
the same relative change whether it starts near black, in the middle, or near
white.

OKHST keeps OKHSL's hue and saturation and replaces lightness with that tone
axis. Under the hood, tone is a monotonic remap of OKHSL lightness: a given tone
always maps to the same lightness at every hue and saturation. Every OKHST color
is therefore a valid OKHSL color and inherits its gamut behavior and
reversibility.

The remap uses a normalized logarithm of luminance, offset by the same 0.05
used in the WCAG contrast formula:

tone(Y) = 100 * (ln(Y + 0.05) - ln(0.05)) / (ln(1.05) - ln(0.05))

The shared offset gives tone its useful behavior. WCAG contrast is
(Y_hi + 0.05) / (Y_lo + 0.05), so for neutral colors a fixed tone difference
corresponds to a fixed contrast ratio, no matter where on the scale it sits.

Here is the same measurement as before, but with equal tone steps instead of
equal lightness steps:

Tone	vs black	vs white	+20 step ×
0	1	21	1.84
20	1.84	11	1.84
40	3.38	6.21	1.84
60	6.21	3.38	1.84
80	11	1.84	1.84
100	21	1	—

Each +20 tone step multiplies contrast by exactly the same factor — 1.84×.
Plain lightness does not provide that property.

Tone lets states be authored as deltas instead of independent colors:

// Illustrative pseudo-code, not a real library call.
const primaryTone = 62;
const hoverDelta = 6;

const primary = okhst({ h: 250, s: 70, t: primaryTone });
const hover = okhst({ h: 250, s: 70, t: primaryTone - hoverDelta });

The same pattern can describe tints, shades, borders, and shadows.

Tone provides a reliable starting relationship, not an accessibility guarantee.
The fixed relationship is exact for neutral colors; once saturation enters,
rendered sRGB luminance can drift from that neutral prediction. A required
contrast floor still has to be checked with WCAG or APCA against the final
rendered color pair.

Even with that boundary, a methodology can say "move tone by this much" and
produce a consistent starting point instead of searching for every color
independently.

OKHST is not a universal color science breakthrough. It is a practical
coordinate system for generating UI palettes.

The full specification is here: github.com/tenphi/okhst

Scheme Mapping

OKHST defines a color coordinate:

hue, saturation, tone

A coordinate alone does not define a theme. The interface adds a separate
scheme layer that decides how authored tones behave in light, dark, and
high-contrast modes. That layer has three parts: tone windows, tone deltas, and
local tone flips.

A tone window maps the authored 0-100 range into the endpoints a scheme
should actually use. For a light scheme, I might use 10-100: pure white
surfaces remain available, while text avoids unnecessarily harsh black. A dark
scheme can invert tone and map it into 15-95, avoiding both black surfaces and
pure white text. High contrast usually opens the window to the full 0-100
range.

A tone delta defines how far a color sits from its parent: a border might be
14 tones away from its surface, for example. Opening the window preserves
that distance, so a subtle border remains subtle. High contrast can widen the
deltas to pull borders, muted text, and accents further from the colors beneath
them.

A local tone flip lets one region reverse direction without changing the
whole scheme. The surrounding interface may follow dark mode while an accent
region keeps its original direction.

Together, these parameters let one authored palette serve light, dark, and both
high-contrast variants instead of becoming four separately maintained
palettes. They are theme logic layered on top of OKHST, not part of the color
space itself.

With the two layers separated, the next question is whether CSS can preserve
their relationships at runtime.

Can This Run in CSS?

The playground keeps the OKHST primitive and its scheme logic live instead of
flattening them into static values. Modern Chromium-based browsers are starting
to support CSS @function, which allows custom functions with real
calculations. This new primitive made an unreasonable experiment possible:

Can OKHSL and OKHST conversion run directly in CSS?

The answer is yes. The functions port OKHSL's gamut-normalized saturation and
emit standard oklch() colors without a JavaScript runtime.

I built a playground here: tenphi.github.io/okhst

The implementation exposes two functions:

/* Raw OKHST primitive: direct hue/saturation/tone conversion. */
--raw-color: --okhst(var(--seed-h), var(--seed-s), 62);

/* UI helper: maps tone into the active scheme before resolving OKHST. */
--ui-color: --ghst(var(--seed-h), var(--seed-s), 62);

--okhst() is the color-space primitive. The scheme-aware --ghst() helper
applies the current tone window and optional flip before calling it.

The playground UI uses the same system as its swatches. Changing hue,
saturation, scheme, or tone window also changes the interface around the ramp.
The two sliders from the opening are now working: hue chooses the color family,
saturation controls its intensity, and the UI follows.

The surrounding interface uses the same seed as the swatches. Each color is
authored as a tone delta from the surface:

:root {
  --seed-h: 250;
  --seed-s: 70;

  /* tone deltas: how far each color steps away from the surface */
  --d-elev: 4;
  --d-border: 14;
  --d-text: 94;
  --d-muted: 62;
  --d-accent: 42;

  --c-surface: --ghst(var(--seed-h), 4, 100);
  --c-elev: --ghst(var(--seed-h), 5, calc(100 - var(--d-elev)));
  --c-border: --ghst(var(--seed-h), 4, calc(100 - var(--d-border)));
  --c-text: --ghst(var(--seed-h), 2, calc(100 - var(--d-text)));
  --c-muted: --ghst(var(--seed-h), 2, calc(100 - var(--d-muted)));
  --c-accent: --ghst(var(--seed-h), var(--seed-s), calc(100 - var(--d-accent)));
}

Saturation and tone both use the 0-100 percent form here. Hue uses degrees,
and low saturations such as 4 are nearly neutral.

Scheme behavior reduces to variables:

:root {
  --tone-lo: 10;
  --tone-hi: 100;
  --tone-flip: 0;
}

html.dark {
  --tone-lo: 15;
  --tone-hi: 95;
  --tone-flip: 1;
}

html.high-contrast {
  /* --tone-flip is inherited from the active light/dark scheme. */
  --tone-lo: 0;
  --tone-hi: 100;

  /* wider steps: relationships pull apart, not just the extremes */
  --d-elev: 6;
  --d-border: 22;
  --d-text: 100;
  --d-muted: 72;
  --d-accent: 50;
}

.accent-zone {
  --tone-flip: 0;
}

Because the interface colors derive from deltas, these overrides implement high
contrast for light and dark at once while keeping tone inversion separate.

The swatches define their own local rules:

.swatch {
  --tone-flip: 0; /* palette itself does not invert in dark mode */
  --t: calc(var(--i) / (var(--count) - 1) * 100);
  --swatch-bg: --ghst(var(--seed-h), var(--seed-s), var(--t));

  background-color: var(--swatch-bg);
  color: --ghst(var(--seed-h), calc(var(--seed-s) * 0.4), calc(100 - var(--t)));
}

Together, the rules keep every color connected:

the swatch tone comes from its index
the text tone is inverted from the background tone
the text saturation is reduced relative to the source saturation
the palette itself opts out of dark inversion
the surrounding UI still follows the active scheme

Rendered with those rules (precomputed, since CSS @function is not widely
shipped yet), the ramp looks like this:

The playground reads final colors with getComputedStyle, but CSS performs the calculation. The first version was slow enough that dragging the hue slider visibly lagged. After I showed it to Roman Komarov, his proof-of-concept explained why: a function-local is re-substituted at every var() that reads it, so one call to the cusp solver expanded its branch gates hundreds of times. Moving those sub-expressions into their own @functions collapses the expansion, because a function call resolves to a single number at the call boundary.

Three factorings of the same math are now published side by side, and the
Measure button in the playground times a style recalc on whichever one is
open:

Version	ms/recalc
`naive`	282
`sub-functions`	46
`optimized`	28

Numbers from an M1 Max, 51-step ramp, dark scheme. naive keeps every
intermediate as a function-local, sub-functions applies Roman’s factoring
unchanged, and optimized adds a cache on top: the hue-only cusp setup is
hoisted to :root so it resolves once per hue instead of once per swatch, and
the OKHST and OKHSL paths are split so each swatch evaluates only the transfer
it needs.

Runtime cost was no longer the main obstacle; browser support was. CSS
@function is Chromium-only today (Chrome/Edge 139+), while Firefox and Safari
have not shipped it, so broad production use is likely still years away.

The experiment still proves that CSS can preserve palette rules instead of
flattening them into static values. The platform is expressive enough for the
model, just not widely supported enough to depend on yet.

The Hue Slider Loophole

Full OKHST conversion in CSS still has to wait, but my blog at tenphi.me already ships one narrow slice of the idea across modern browsers.

The palette icon in its top bar opens a hue slider. Dragging it rotates the
site's text, surfaces, borders, and accents without @function or JavaScript
color math. Underneath is the same pattern I called fragile earlier:

--text-color: oklch(0.201 0.0014 var(--primary-hue));

The apparent contradiction disappears because every rotating color stays
inside what I call pastel space: chroma remains below the level that fits
inside sRGB for every hue at that lightness. Within that boundary, hue can
rotate without clipping or overshooting.

The shortcut has three costs:

Saturation is capped. Pastel space excludes vivid colors.
Only hue remains dynamic. Tone windows, state changes, and deltas must be baked into static values.
Each pastel limit must be precomputed. Otherwise, every color needs a CSS function or an impractically large inline calculation.

The site performs that work at build time, leaving only hue as a custom
property. The loophole is useful but narrow: one dynamic axis, muted colors,
and precomputation behind the scenes. A production system has to provide that
precomputation.

From Experiment to Production

tenphi / glaze

OKHST-based accessible color palette generator with support for dark and high-contrast themes.

Glaze

OKHST-based color theme generator with WCAG and APCA contrast solving

Glaze generates light, dark, and high-contrast color schemes from a single hue/saturation seed. Relationships stay explicit: colors either define an absolute tone or depend on a named base through a tone delta and an optional contrast floor.

Features

OKHST color space — OKHSL with a contrast-shaped tone axis. Equal steps give equal WCAG contrast for neutrals and a useful approximation for chromatic colors. See OKHST in Glaze and the full OKHST specification.
WCAG 2 + APCA contrast solving — automatic tone adjustment to meet a WCAG ratio or APCA Lc floor
Unified dark mode — one tone space for light, dark, and high-contrast; dark is a single 100 − t inversion, no fitted curve
Mix colors — blend two colors with OKHSL or sRGB interpolation, opaque or transparent, with optional contrast solving
Shadow colors — OKHSL-native…

View on GitHub

Glaze provides that precomputation layer. It applies OKHST and resolves the palette rules that browsers cannot yet evaluate broadly at runtime. It supports dependent colors, solves WCAG and APCA contrast, handles light, dark, and high-contrast schemes, and exports standard design-token formats.

tenphi.me is a live demo. Glaze generates its hue-rotating UI palette and its syntax-highlighting palette. The dark and high-contrast modes behind the same palette icon are scheme remaps computed at build time: parameter changes rather than hand-authored alternate palettes. tasty.style uses the same approach for its theme variants.

The model also scales beyond a single site. Cube UI Kit, an open-source React library with more than 100 components that powers Cube products, uses one set of Glaze palette rules across its component library. Glaze deserves its own article because it provides a palette-building methodology, not just a color-space implementation.

Closing

The goal is not to make UIs more colorful. It is to make the boring parts of color reliable.

Normalized saturation keeps hue and lightness changes inside a usable gamut. Tone turns movement along the lightness axis into regular contrast steps. Scheme mapping builds those properties into reusable rules for states, dark mode, and high contrast. Glaze precomputes those rules for production today.

OKHST is not perfect or universal, but it gives UI color generation a more useful set of coordinates. The question from the opening is no longer hypothetical: open tenphi.me, click the palette icon in the top bar, drag the hue slider, and watch the boring parts follow.

Why I spent years trying to make CSS states predictable

Andrey Yamanov — Thu, 23 Apr 2026 12:11:25 +0000

Have you ever changed the order of two CSS rules and broken a component without changing the logic?

.btn:hover {
  background: dodgerblue;
}
.btn[disabled] {
  background: gray;
}

Both selectors have specificity (0, 1, 1). When a button is both hovered and disabled, the browser falls back to source order. If the :hover rule comes last, the disabled button turns blue. If the [disabled] rule comes last, it stays gray.

That looks like a small edge case, but it points to a bigger problem: component state in CSS often works by overlap.

With only one or two states, that overlap feels manageable. Add :hover, :active, disabled, dark mode, breakpoints, data attributes, container queries, and overrides, and you are no longer just writing styles. You are maintaining a state-resolution system in your head.

I kept running into this while building component systems: real buttons, inputs, panels, dropdowns, and design-system primitives. Writing the first version was rarely the difficult part. Extending it later without reopening the entire state-resolution problem was.

The result was more than the occasional source-order bug. As requirements accumulated, even small customizations became harder to make safely.

At some point I stopped asking, "How do I write this selector?" and started asking a better question:

What if component state could be expressed declaratively, while the compiler handled the selector logic needed to make it deterministic?

That question eventually became Tasty.

The idea in one minute

Instead of writing selectors that compete through cascade and specificity, I wanted to describe a property's possible states as a map:

import { tasty } from '@tenphi/tasty';

const Button = tasty({
  as: 'button',
  styles: {
    fill: {
      '': '#primary',
      ':hover': '#primary-hover',
      ':active': '#primary-pressed',
      '[disabled]': '#surface',
    },
  },
});

Read in order of priority, this means:

if the button is disabled, use #surface
otherwise, if it is active, use #primary-pressed
otherwise, if it is hovered, use #primary-hover
otherwise, use #primary

The important part is what happens next.

Tasty compiles that state map into selectors that cannot overlap:

/* [disabled] wins outright */
.t0[disabled] {
  background: var(--surface-color);
}
/* :active is excluded when disabled */
.t0:active:not([disabled]) {
  background: var(--primary-pressed-color);
}
/* :hover is excluded when :active or disabled */
.t0:hover:not(:active):not([disabled]) {
  background: var(--primary-hover-color);
}
/* default is excluded when anything above matches */
.t0:not(:hover):not(:active):not([disabled]) {
  background: var(--primary-color);
}

No selector conflict remains for specificity or source order to settle. Only one branch can match at a time.

The real payoff comes later: changing or extending the map is much easier than reconstructing the equivalent selector relationships by hand.

That is the central idea:

If the author defines the priority, the generated selectors should make that priority unambiguous.

Why this matters more than the button example suggests

A hovered disabled button is simply the easiest way to see the problem. The real difficulty begins when conditions intersect in less obvious ways.

Maybe dark mode can come from a root attribute, or from prefers-color-scheme, or from both. Maybe spacing changes inside a narrow container, but only on tablet widths. Maybe a destructive variant behaves differently on hover but not when loading. Maybe a parent theme toggles a child override.

Each rule is understandable in isolation. The difficulty lies in keeping their relationships predictable. Small edits can change which branches overlap. A harmless refactor can turn into a source-order bug. Extending an existing component can mean reopening selector logic you thought was already settled.

I wanted a model where adding a new state did not mean mentally re-deriving the whole selector matrix.

A slightly bigger example

Consider a reusable action card. It can appear in the main content or a narrow sidebar, adapt its layout to the viewport, and represent either a regular or destructive action:

const ActionCard = tasty({
  as: 'button',
  styles: {
    flow: {
      '': 'column',
      '@media(w >= 768px)': 'row',
    },
    fill: {
      '': '#surface',
      '@root(schema=dark)': '#surface-dark',
      'theme=danger': '#danger',
      'theme=danger & :hover': '#danger-hover',
    },
    padding: {
      '': '4x',
      '@(sidebar, w < 300px)': '2x',
    },
  },
});

The card stacks its contents by default and arranges them in a row on wider screens. Its background follows the root color scheme unless the danger theme applies, with a separate danger hover state. Inside a narrow sidebar container, its padding shrinks. The author declares these decisions next to the properties they affect; the compiler handles their selector relationships and priority.

The object-shaped representation has another practical consequence. All styles for a particular element and its sub-elements can live in a single style object. Merging a second style object into the first naturally extends the entire definition—including its state maps—without sending the author back to scattered selector overrides.

That makes extension a form of data composition. Authors combine style definitions; the compiler resolves the resulting states. This matters because a component system rarely stays as it was first written.

Why it took so long

The core idea is simple. Turning it into a system I could trust across a design system took several years and hundreds of iterations.

Producing one clever selector was not the challenge. The system had to remain coherent when all of these appeared together:

pseudo-classes like :hover and :active
attributes, boolean modifiers, and value-based modifiers
root-level state
media queries
container queries
nested and compound selectors
merging style objects across elements and sub-elements
typed APIs on top of the styling model

Supporting each feature was only part of the work. Every addition also had to compose with everything already there. Media queries had to coexist with modifiers. Root state had to coexist with pseudo-classes. Extending a style object had to preserve its declared priorities rather than quietly reshuffle them.

As the model grew, I repeatedly had to test whether the original idea still held up. Sometimes it did. Sometimes it very much did not. There were stretches where I broke the DSL, reconsidered how states should be represented internally, and rebuilt large parts of the compiler to preserve the same promise.

The technical work involved parsing, normalization, selector generation, caching, extension rules, and making the output fast enough to be practical. The conceptual work was deciding what Tasty actually was.

Was it a nicer CSS object format? An atomic CSS generator? A design-system language? A compiler for stateful component styles? For a while, Tasty seemed to be all of these at once. The difficult part was finding boundaries that made those roles reinforce one another instead of compete.

For a long time I honestly did not know whether the idea could scale cleanly enough to justify the effort. It worked in pockets early. Making it dependable across a design system took much longer.

Tasty has powered Cube UI Kit from the beginning. That system now spans 100+ components and powers Cube Cloud, a real enterprise product. Early versions were absolutely experimental internally. Production pressure and team feedback exposed where the model held up and where it needed to change.

The part I care about most

I do not think mutually exclusive selectors are interesting merely because they are clever. They are interesting because they remove a category of ambiguity that should not be the author's job in the first place.

When I style a component, I want to describe what it should look like in each meaningful state. I do not want to manually encode the browser's tie-breaker logic every time those states intersect.

That is the payoff Tasty is chasing:

predictable component behavior
fewer accidental regressions from source order
easier extension through composable style objects
a styling model that becomes more valuable as the design system grows

If you are styling a small landing page, this is probably too much machinery. Plain CSS is often the right answer.

If you are building components that need to survive years of iteration, variant growth, theme expansion, and multiple authors, predictability starts compounding in a practical way.

Tasty also has typed component APIs, sub-elements, SSR integrations, zero-runtime extraction, editor tooling, linting, tokens, recipes, and more. Those features matter, but they are downstream of the principle that motivated the project:

Component states should be easy to describe and hard to make ambiguous.

That sentence took years to turn into a tool I was comfortable releasing.

If this resonates

You can try Tasty in the browser with the playground, or read the docs if you want the full language and feature set.

If you try it, I would especially like to hear where the model clicks, where it feels unfamiliar, and where the documentation skips a mental step. That kind of feedback has shaped the project from the beginning, and it still does. The best place to share it is GitHub Issues.

Tasty grew from a problem I kept encountering for years. If that problem feels familiar, I would love to know whether this model helps.

Links: Docs | Playground | GitHub | npm | Telegram