Forem: Olexandr Uvarov

SCSS Is Solving Problems CSS Is Learning to Solve Itself

Olexandr Uvarov — Tue, 31 Mar 2026 09:53:58 +0000

You've spent years reaching for SCSS the moment a project grows past a single stylesheet. Variables. Loops. Functions. Nesting. It felt like the only sane way to write scalable CSS.

Meanwhile, native CSS has been quietly shipping the same features — one by one, browser by browser.

So here's the honest question: how much of SCSS do you actually still need?

Let me walk through what CSS can do natively today, what's coming next, and where SCSS still wins.

What CSS Can Do Right Now

Custom Properties (aka CSS Variables)

You already know these. They replaced SCSS $variables for runtime use-cases — and they're strictly more powerful because they cascade, they're dynamic, and JavaScript can interact with them.

:root {
  --color-primary: #ff69b4;
  --spacing-base: 8px;
}

.button {
  background: var(--color-primary);
  padding: calc(var(--spacing-base) * 2);
}

SCSS variables are build-time only. Custom properties survive into the browser. If you haven't fully made the switch for your design tokens, that's where to start.

Nesting

Native CSS nesting shipped in Chrome 112 (2023) and is now in every major browser. The syntax is almost identical to SCSS:

.card {
  padding: 16px;

  &__title {
    font-size: 18px;
  }

  &:hover {
    box-shadow: 0 4px 12px rgba(0, 0, 0, 0.1);
  }

  @media (max-width: 768px) {
    padding: 12px;
  }
}

Two differences worth knowing before you migrate:

& is mandatory in native CSS. .card h1 {} nested inside .card {} won't work — you need & h1 {}.
No interpolation. SCSS lets you write &#{$modifier} to build dynamic selectors. Native CSS nesting has no equivalent — those cases still need a preprocessor.

For most codebases, neither matters day-to-day. But if you're running BEM with dynamic modifiers or generating selectors in loops, you'll hit the wall.

`color-mix()` and Color Functions

SCSS has lighten(), darken(), mix(). Native CSS now has color-mix():

.button-hover {
  background: color-mix(in oklch, var(--color-primary) 80%, white);
}

The in oklch part tells the browser which color space to interpolate in. This matters more than it sounds: mixing colors in srgb (the default) can produce muddy mid-tones. oklch is perceptually uniform — meaning the lightness you see actually matches the lightness you specified. Tints and shades look consistent instead of just mathematically being consistent.

Supported in all modern browsers. Works with CSS custom properties, which SCSS color functions don't.

`@layer`

This is the one CSS feature that genuinely has no SCSS equivalent because it solves a problem SCSS can't even address: specificity wars at scale.

Quick context if you haven't lived through one: you import a third-party component library. Its .button styles have higher specificity than yours. You add !important. They update the library and add !important too. Now you're writing !important !important in your head and nothing is predictable. @layer fixes this at the architecture level.

@layer reset, base, components, utilities;

@layer reset {
  * { box-sizing: border-box; }
}

@layer components {
  .button { background: var(--color-primary); }
}

@layer utilities {
  /* This ALWAYS wins over components, regardless of specificity */
  .mt-4 { margin-top: 16px; }
}

Layer order controls override priority — not specificity, not source order, not !important. Later-declared layers win. If you're building a design system that external teams can extend without fighting the cascade, this is the tool.

Container Queries

For years, the argument was "CSS can't do what JavaScript can do for responsive design." Container queries close that gap:

.card {
  container-type: inline-size;
}

@container (min-width: 400px) {
  .card__title {
    font-size: 24px;
  }
}

Components that adapt to their parent container, not the viewport. Media queries were always the wrong abstraction for component libraries — this is the right one.

What's Coming Next (and When to Care)

⚠️ Everything in this section is not yet in browsers (or only behind experimental flags). The syntax shown is from active CSS Working Group specs — real and moving forward, but not production-ready. If you want to use any of this today, PostCSS has polyfill plugins for most of it. More on that at the end.

`@function` — Native CSS Functions

This is the big one. The CSS Working Group has a specification in progress for custom functions directly in CSS. No JavaScript, no SCSS:

/* Proposed syntax — not in browsers yet */
@function --spacing($multiplier) {
  result: calc(8px * $multiplier);
}

.card {
  padding: --spacing(3); /* 24px */
}

This would replace one of SCSS's most-used features. Timeline: likely 2025-2026 for an experimental flag, broader support a year or two after that.

`@mixin` — Native CSS Mixins (sort of)

Also in the CSS Mixins & Functions spec. The concept: reusable blocks of declarations, applied without a preprocessor:

/* Proposed syntax */
@mixin --flex-center {
  display: flex;
  align-items: center;
  justify-content: center;
}

.hero {
  @apply --flex-center;
}

Important caveat for anyone who's used SCSS mixins heavily: this is a significantly simpler model. No @content injection. No arguments with conditional logic. No @if inside the mixin body. It's closer to a named block of static declarations than a parametric function. Think of it as CSS @extend done right — not SCSS @mixin done natively. The name is similar; the power level is not.

`if()` — Inline Conditionals

CSS is getting inline conditional logic as part of the Values Level 5 spec:

.button {
  /* Adjust padding based on a custom property flag */
  padding: if(style(--size: large): 20px 32px; else: 12px 20px);
}

Combined with custom properties as flags, this lets components adapt their own styles based on configuration — no JavaScript, no modifier classes, no SCSS conditionals.

Relative Color Syntax

Already shipped in Chrome and Safari, making its way to Firefox:

.button-hover {
  /* Take primary color, keep h and s, reduce l by 10% */
  background: hsl(from var(--color-primary) h s calc(l - 10%));
}

This replaces lighten() and darken() with something more predictable and composable. Works with custom properties, which SCSS functions don't.

Where SCSS Still Wins (For Now)

Being honest here — the answer isn't "CSS wins completely." There are three areas where SCSS still has a real advantage in 2025:

1. Loops and data-driven generation

@for, @each, @while — CSS has nothing equivalent yet. If you're generating 16 animation delays for a visualizer, or creating utility classes from a scale map, SCSS loops are still the only build-time option. The proposed CSS @function spec doesn't include iteration.

2. Build-time validation

SCSS @error and @warn fire at compile time. If your design token is missing, you find out before the browser renders anything. CSS has no equivalent concept — it fails silently.

@if not map-has-key($modes, $mode) {
  @error "Unknown mode: #{$mode}. Available: #{map-keys($modes)}";
}

There's no native CSS equivalent coming. This remains a preprocessor-only capability.

3. Complex structured data

SCSS maps as nested data structures — $modes: (pink-big: (title: (color: ..., font-size: ...))) — are genuinely expressive in ways CSS custom properties can't replicate. CSS properties are flat key-value. SCSS maps are traversable trees. For the kind of multi-mode theming system I wrote about in the first article in this series, SCSS maps as a config layer still make sense even when CSS handles the runtime switching.

The Middle Ground Nobody Talks About: PostCSS

The "SCSS vs native CSS" framing misses a third option that's already how many production setups work: PostCSS.

PostCSS sits between your source files and the browser. It's not a preprocessor like SCSS — it's a transformation pipeline. You write future CSS syntax, PostCSS compiles it to what browsers support today.

The practical upside: you can use @custom-media, CSS nesting (even before it was fully shipped), relative color syntax, and some of the proposed @function syntax right now via PostCSS plugins. Vite has PostCSS built in. Next.js does too.

// postcss.config.js
module.exports = {
  plugins: [
    require('postcss-nesting'),          // native nesting polyfill
    require('postcss-custom-media'),     // @custom-media queries
    require('postcss-oklab-function'),   // oklch/oklab color support
  ]
}

This is worth knowing because it changes the timeline question. You don't have to wait 2-3 years for @function to ship in browsers — you can write it today if PostCSS has a plugin for it. The CSS ecosystem is converging on this model: specify in CSS, transform at build time, no preprocessor lock-in.

The Risks Nobody Mentions

Going native CSS isn't just a technical decision — it's a bet on your users' browsers. Here's what can go wrong.

You don't actually know what browsers your users run

"All modern browsers support it" is a statement about the latest versions. Your users might not be on the latest versions.

The gap is bigger than you think:

Corporate users on locked-down Windows machines often run Chrome that's 6-12 months behind
Android WebView (used inside apps, not the standalone browser) updates on its own schedule and frequently lags
Safari on iOS is tied to the OS version — users on iPhone 8 running iOS 15 are stuck on Safari 15, and iOS 15 was dropped from Apple's update cycle in 2022

/* CSS nesting — ~93% global support */
/* container queries — ~91% global support */
/* color-mix() — ~89% global support */
/* @layer — ~92% global support */
/* relative color syntax — ~86% global support */

That 7-14% that doesn't support it isn't a rounding error. If you have 500,000 users, that's 35,000–70,000 people seeing broken styles — silently, with no error in your logs.

CSS fails silently, SCSS fails loudly

This is the asymmetry that matters most in production.

When an SCSS build fails, your CI pipeline fails. The broken code never ships. With native CSS, the browser just skips the declaration it doesn't understand and moves on:

.card {
  /* Browser doesn't understand container queries → skips silently */
  container-type: inline-size;
  /* Falls back to... nothing. No fallback defined. Layout breaks. */
}

No error. No warning. No alert. You find out when a user screenshots a broken UI and posts it somewhere.

SCSS gave you build-time safety. Native CSS gives you runtime silence.

The progressive enhancement tax

The correct answer to browser support gaps is progressive enhancement — define a baseline that works everywhere, then layer on the modern feature:

.card__title {
  /* Baseline: works everywhere */
  font-size: 18px;
}

/* Enhancement: only where container queries work */
@container (min-width: 400px) {
  .card__title {
    font-size: 24px;
  }
}

This is the right pattern. But it's also more code, more cognitive load, and more surface area to test. With SCSS you compiled one output and called it done. With native CSS + progressive enhancement you're maintaining two layers of intent for every feature you use. It's manageable. But it's not free.

`@supports` helps — but only partially

Unlike JavaScript where you can if ('IntersectionObserver' in window), CSS has no clean runtime feature detection. @supports gets you partway there:

@supports (container-type: inline-size) {
  .card { container-type: inline-size; }
}

@supports not (container-type: inline-size) {
  /* fallback layout */
}

But @supports checks syntax, not behavior. Some older browsers will claim to support a feature and implement it incorrectly. You don't find out until QA on a real device — or until a user reports it.

The practical checklist before going SCSS-free

Before committing to native-CSS-only on a project, answer these four questions:

1. What does your analytics say about browser versions?
If you have >5% traffic on browsers older than 2 years, you need fallbacks for almost everything in this article.

2. Do you test on real devices?
Chrome DevTools device emulation is not the same as a real Android 10 device. Android WebView lags behind Chrome proper and is where you'll catch the most rendering bugs — but only if you actually test there.

3. What's your fallback strategy when a feature isn't supported?
"It probably works" isn't a strategy. Define explicitly: if @layer doesn't load, what does the user see? If container queries don't fire, does the layout degrade gracefully or snap into something broken?

4. Does your team have the CSS depth to debug this?
SCSS errors are compiler errors — they're explicit. Native CSS failures are visual regressions with no stack trace. You need someone on the team who can open DevTools, spot a silently-ignored declaration, and trace it back to a support gap. That's a different skill than reading a build log.

The Honest Answer to "Can We Drop SCSS?"

For new projects starting today: probably yes, with caveats. Native nesting, custom properties, color-mix(), container queries, and @layer handle the majority of what SCSS used to be required for. You'd miss loops and build-time validation.

For existing projects: almost certainly no, not yet. The migration cost isn't justified by the current feature delta. The gap is closing, but it's not closed.

The direction is clear though. Every SCSS feature that can be replicated natively will be replicated natively — that's been the pattern for ten years. Variables came first. Nesting followed. Functions and mixins are in spec. The browser is slowly absorbing the preprocessor.

The question isn't whether SCSS will become optional — it's when. My guess: two to three years before native CSS covers enough ground that starting a new project without a preprocessor stops feeling like you're handicapping yourself.

Until then, the smart play isn't "all SCSS" or "all native CSS." It's knowing which problems each solves better right now — and not reaching for a build tool out of habit when the platform handles it.

The real question isn't which individual feature you'd miss — it's whether you'd lose a workflow. Build-time validation, structured data as config, loop-driven generation: these aren't features you replace one-for-one, they're patterns. What pattern from your SCSS setup do you think CSS will never cover natively? Drop it in the comments.

I Crashed a Mobile Browser With One CSS Property. Here's What I Learned About Rendering.

Olexandr Uvarov — Tue, 17 Mar 2026 16:16:22 +0000

A few months ago, I was debugging a checkout flow on mobile. Everything looked fine on desktop — smooth step transitions, nice fade-ins, snappy UI. Then QA pinged me: "the payment page freezes on iPhone SE for ~2 seconds when opening."

I opened Web Inspector, navigated to the Layers panel, and my jaw dropped. What should have been 3–4 composite layers turned into 34. Every pricing card, every badge, every animated element had been silently promoted to its own GPU layer. The page was eating over 200 MB of GPU memory just to show a pricing table.

The fix? Moving one z-index and removing two will-change declarations. Three lines of CSS.

But to understand why that worked, you need to understand how browsers actually render pages. And that's what this article is about.

The rendering pipeline: from HTML to pixels

Every time a browser displays a webpage, it follows a pipeline. Think of it like a factory assembly line — each stage builds on the previous one:

  HTML ──► DOM
                ──► Render Tree ──► Layout ──► Paint ──► Composite ──► 🖥️
  CSS  ──► CSSOM                   (Reflow)   (Repaint)   (GPU)

Quick walkthrough:

DOM + CSSOM → Render Tree. The browser parses HTML into a DOM tree and CSS into a CSSOM. It merges them into a Render Tree — but not everything makes it in. display: none elements are excluded (they don't take up space). visibility: hidden elements stay (invisible but still occupy layout). Pseudo-elements like ::before get added even though they're not in the DOM.

Layout (Reflow). The browser walks the Render Tree and calculates where and how big every element is. It starts from the root and works down, sometimes making multiple passes when later elements affect earlier ones.

Paint (Repaint). Now it knows the geometry — time to fill in the pixels. Colors, borders, text, shadows, backgrounds.

Composite. The browser splits the page into layers, rasterizes them, and hands them to the GPU, which combines everything into the final image you see.

The first three stages run on the main thread (same thread as your JavaScript). The last one runs on a separate compositor thread. This distinction is everything for animation performance.

Reflow: the expensive one

Reflow is the browser recalculating layout. It's triggered by anything that changes an element's geometry — and it cascades. Change the width of a parent, and every child might need to be recalculated too.

What triggers it:

/* All of these invalidate layout: */
width, height, margin, padding, border,
display, position, top, left, right, bottom,
font-size, font-weight, line-height, float,
overflow, text-align, vertical-align, white-space

But here's the part that bites people in code reviews — reading layout properties forces a synchronous Reflow:

// ❌ Layout thrashing — forces Reflow on EVERY iteration
for (let i = 0; i < cards.length; i++) {
  const height = cards[i].offsetHeight;     // READ → forces sync reflow
  cards[i].style.height = height + 10 + 'px'; // WRITE → invalidates layout
}

// ✅ Batch reads first, then writes
const heights = cards.map(c => c.offsetHeight);
heights.forEach((h, i) => {
  cards[i].style.height = h + 10 + 'px';
});

Properties like offsetHeight, offsetWidth, getBoundingClientRect(), scrollTop, clientLeft — all of them force the browser to stop everything and recalculate layout immediately to give you an accurate number.

📎 Paul Irish maintains the definitive list: what-forces-layout.md

Repaint: cheaper, but still not free

Repaint happens when visual properties change without affecting geometry — colors, shadows, outlines, visibility.

The key relationship to memorize:

Reflow  → ALWAYS triggers Repaint (layout changed → must redraw)
Repaint → NEVER triggers Reflow (visual change only → no geometry recalc)

Quick comparison:

/* Triggers Reflow + Repaint — removed from layout entirely */
display: none;

/* Triggers only Repaint — invisible but keeps its space */
visibility: hidden;

/* Triggers only Composite — cheapest path, GPU only */
opacity: 0;

Three ways to hide an element, three very different performance costs.

Composite: where animations become smooth (or crash your browser)

This is the stage that makes 60fps animations possible — and the stage that can eat all your GPU memory if you're not careful.

After painting, the browser groups elements into layers and sends them to the GPU. The GPU's job is simple: take these pre-rendered images and move/transform/blend them. It's incredibly fast at this because that's literally what GPUs were built for.

This is why transform and opacity animations are smooth — they only need Composite. The GPU just shifts a cached texture around. No Layout. No Paint. No main thread involvement at all.

☝️ This demo has two balls bouncing side to side. The green one uses CSS transform (compositor thread). The red one uses JS requestAnimationFrame (main thread). Hit "Block Main Thread" and watch: the green ball keeps moving while the red one freezes for 2 seconds. That's the compositor thread in action.

The GPU is a separate computer

This mental model changed everything for me. The GPU isn't just "a fast part of your CPU." It's a separate device with its own memory. The browser has to:

Rasterize each layer into a bitmap image (on CPU)
Upload that bitmap to GPU memory
Send instructions (position, transforms, opacity values)

It's like an AJAX request — you can't tell the server "just grab this from the DOM." You have to serialize the data and send it. Except here, instead of JSON over the network, you're sending pixel data over a memory bus. And those extra milliseconds of transfer time? They're the "flicker" you sometimes see at the start of an animation.

Memory: the silent killer

Every composite layer is stored as an uncompressed RGBA bitmap in GPU memory:

Layer memory = width × height × 4 bytes

What you're rendering	Memory
One 320×240 element	300 KB
10-slide carousel (800×600) with `will-change`	19 MB
Same carousel on 2× Retina	76 MB
Same carousel on 3× mobile display	172 MB

That 320×240 red rectangle? It's 104 bytes as a PNG. In GPU memory, it's 300 KB. The GPU doesn't do PNG. It stores raw pixels.

An iPhone SE has roughly 200–300 MB available for your entire page's GPU layers. One poorly optimized component can eat all of it.

Implicit compositing: the bug you didn't write

This is what crashed my checkout page. And I bet you have it in your codebase right now.

Setup: Element A sits above element B (higher z-index). You animate B with transform. The browser promotes B to its own GPU layer for the animation.

Problem: Element A must visually stay above B. But A is still on the base layer. The GPU composites layers in order — it can't interleave elements from different layers. So the browser is forced to promote A to its own layer too, even though A has nothing to do with the animation.

Before animation:
┌─────────────────────┐
│  Base layer          │
│  ┌─A─┐              │  A and B both painted on
│  │   │  ┌─B─┐       │  the same base layer
│  └───┘  │   │       │
│         └───┘       │
└─────────────────────┘

During B's transform animation:
┌─────────────────────┐
│  Base layer          │  Layer 1: base (repainted without A and B)
│                      │
└─────────────────────┘
┌─────────────────────┐
│  B layer             │  Layer 2: B (for animation)
└─────────────────────┘
┌─────────────────────┐
│  A layer             │  Layer 3: A (IMPLICIT — just to stay on top!)
└─────────────────────┘
                          GPU composites: 1 → 2 → 3

That's implicit compositing. You didn't ask for this. The browser did it behind your back to preserve correct visual ordering. Each extra layer means:

Extra Repaint to create the layer texture
Extra memory on the GPU
Extra transfer time CPU → GPU

On my checkout page, I had an animated background behind pricing cards. Every card, every badge element sitting above it got implicitly promoted. 34 layers. 200+ MB.

The fix:

/* ✅ Keep animated elements on TOP of stacking context */
.animated-bg {
  position: fixed;
  z-index: -1;  /* below content — no implicit compositing */
}

/* or explicitly promote only what needs it */
.pricing-card {
  position: relative;
  z-index: auto; /* don't create new stacking context unnecessarily */
}

Layer squashing: when the browser "helps" and makes it worse

Modern browsers try to be smart about implicit compositing. When multiple overlapping elements get promoted to separate layers, the browser may squash them into a single shared layer to save memory. This is called Layer Squashing — and most of the time, it works great.

But sometimes it backfires. Imagine 20 small badges overlapping an animated element. Instead of 20 tiny layers, the browser squashes them into one giant layer that covers the bounding box of all 20 badges combined. That single merged layer can end up consuming more memory than the 20 small ones would have.

20 small layers:  50×50×4 × 20 = 200 KB  ✅
1 squashed layer: 800×600×4    = 1.9 MB  😱

If you spot this in DevTools (one mysteriously large layer covering a big area), you can disable squashing by giving each element a slightly different translateZ value:

/* Force separate layers — prevents squashing */
.badge:nth-child(1) { transform: translateZ(0.0001px); }
.badge:nth-child(2) { transform: translateZ(0.0002px); }
.badge:nth-child(3) { transform: translateZ(0.0003px); }
/* ... */

The browser sees elements on different "planes" in 3D space and can't merge them. Use this trick sparingly and only when DevTools confirms squashing is the problem — in most cases the browser's default behavior is fine.

Practical optimizations

1. Only animate `transform` and `opacity`

These are the only properties guaranteed to skip Layout and Paint:

/* 🐌 CPU: Layout → Paint → Composite on EVERY frame */
@keyframes slide-bad {
  from { left: 0; }
  to   { left: 200px; }
}

/* 🚀 GPU: Composite ONLY */
@keyframes slide-good {
  from { transform: translateX(0); }
  to   { transform: translateX(200px); }
}

Need to animate color? Fake it with a pseudo-element and opacity:

.button {
  background: #3b82f6;
  position: relative;
}
.button::after {
  content: '';
  position: absolute;
  inset: 0;
  border-radius: inherit;
  background: #1d4ed8;
  opacity: 0;
  transition: opacity 0.2s;
}
.button:hover::after {
  opacity: 1;
}

2. `transition` vs `@keyframes` — and a common misconception

CSS gives you two ways to animate: Transitions and Animations (@keyframes). Both can run on the compositor thread — but only if you animate the right properties.

Transitions react to a state change. Point A → Point B. Simple.

/* Transition: fires when .active class is added/removed */
.card {
  transition: transform 0.3s ease;
}
.card.active {
  transform: translateY(-10px);
}

@keyframes define a multi-step animation. Can loop, run automatically, go forward and backward.

/* Animation: starts immediately, loops forever */
.spinner {
  animation: spin 1s linear infinite;
}
@keyframes spin {
  from { transform: rotate(0deg); }
  to   { transform: rotate(360deg); }
}

Here's the misconception I see all the time: developers think that just using @keyframes automatically means GPU-accelerated, smooth animation. It doesn't. What matters is WHICH properties you animate, not HOW you animate them.

/* ❌ @keyframes but STILL triggers Reflow every frame */
@keyframes grow-bad {
  from { width: 100px; height: 100px; }
  to   { width: 300px; height: 300px; }
}

/* ❌ Same problem — visibility triggers Repaint every frame */
@keyframes blink-bad {
  0%   { visibility: visible; }
  50%  { visibility: hidden; }
  100% { visibility: visible; }
}

/* ✅ Composite only — GPU handles this entirely */
@keyframes grow-good {
  from { transform: scale(1); }
  to   { transform: scale(3); }
}

/* ✅ Composite only — no Repaint, no Reflow */
@keyframes fade-good {
  0%   { opacity: 1; }
  50%  { opacity: 0; }
  100% { opacity: 1; }
}

The same rule applies to transitions:

/* ❌ transition on width — Reflow on every frame */
.panel {
  width: 0;
  transition: width 0.3s ease;
}
.panel.open {
  width: 400px;
}

/* ✅ transition on transform — Composite only */
.panel {
  transform: scaleX(0);
  transform-origin: left;
  transition: transform 0.3s ease;
}
.panel.open {
  transform: scaleX(1);
}

Both panels look like they're expanding. But the first one forces the browser to recalculate layout for the panel and everything around it, 60 times per second. The second one just tells the GPU to stretch a cached texture.

Quick rule: @keyframes and transition are just delivery mechanisms. The performance depends entirely on which CSS properties are inside them. transform and opacity → GPU fast path. Anything else → main thread, Reflow/Repaint on every frame.

3. CSS animations > JS animations

CSS animations are declarative — the browser knows start, end, and duration upfront, so it pre-calculates everything and ships it to the GPU compositor thread.

JS animations are imperative — you compute each frame yourself, 60 times per second, on the main thread. If any JS computation takes too long, your animation stutters.

// JS animation — hostage to main thread
function animate() {
  el.style.transform = `translateX(${pos}px)`;
  pos += 2;
  if (pos < 200) requestAnimationFrame(animate);
}

// If something heavy runs on main thread → animation freezes

/* CSS animation — runs on compositor thread, immune to JS blocking */
.element {
  transition: transform 0.3s ease;
}
.element.active {
  transform: translateX(200px);
}

The third option: Web Animations API

There's actually a middle ground between "pure CSS" and "manual rAF loop." The Web Animations API (Element.animate()) gives you JavaScript's flexibility with CSS animation's performance:

// Web Animations API — runs on compositor thread like CSS,
// but with full JS control: pause, reverse, seek, dynamic values
const card = document.querySelector('.card');

const animation = card.animate([
  { transform: 'translateY(0px)', opacity: 1 },
  { transform: 'translateY(-20px)', opacity: 0.8 },
  { transform: 'translateY(0px)', opacity: 1 }
], {
  duration: 600,
  easing: 'cubic-bezier(0.34, 1.56, 0.64, 1)', // spring-like
  iterations: 1
});

// Full control — things CSS can't do easily:
animation.pause();
animation.reverse();
animation.playbackRate = 0.5;  // slow motion
animation.currentTime = 300;   // seek to middle

animation.onfinish = () => {
  console.log('Animation complete!');
};

Why this matters: Element.animate() is declarative under the hood — the browser receives the full animation description upfront (just like @keyframes) and can hand it to the compositor thread. But unlike CSS, you get pause, reverse, seek, dynamic playback rate, and finish callbacks — all without touching requestAnimationFrame.

The rule of thumb:

Simple hover/toggle effects → CSS transition
Looping, multi-step, auto-playing → CSS @keyframes
Dynamic, interactive, need JS control → Element.animate()
Physics-based, gesture-driven → requestAnimationFrame (last resort)

4. `will-change` — and the hack it replaced (formerly `translateZ(0)`)

Before will-change, developers used a hack to force GPU layer promotion:

/* The OG GPU hack (circa 2012–2016) */
.old-school {
  transform: translateZ(0);
  /* or */
  transform: translate3d(0, 0, 0);
}

This worked because any 3D transform forces the element onto a separate composite layer. It was the zoom: 1 of GPU rendering — a side effect abused as a feature.

will-change replaced it as the proper, intentional API:

/* ❌ Old: hack, no intent, always-on, wastes memory */
.element { transform: translateZ(0); }

/* ✅ Modern: communicates intent to the browser */
.element { will-change: transform; }

/* ✅✅ Best: apply only when needed, remove when done */
.card:hover { will-change: transform; }
.card:active { transform: scale(0.97); }

But will-change still creates a real composite layer with real memory cost. It's not a magic "go fast" property — it's a resource allocation.

/* ✅ Good: applied just before animation starts */
.card:hover {
  will-change: transform;
}
.card:active {
  transform: scale(0.95);
}

/* ❌ Bad: applied to everything "just in case" */
* {
  will-change: transform; /* congratulations, you've eaten all GPU memory */
}

Every will-change: transform element gets its own layer → its own RGBA bitmap → its own chunk of GPU memory. Use it only when you know an animation is about to happen, and remove it when the animation is done.

5. Shrink your layers

The GPU stores raw pixels. Smaller element = smaller texture = less memory:

/* ❌ 100×100 layer = 40,000 bytes in GPU memory */
.large-layer {
  width: 100px;
  height: 100px;
  will-change: transform;
}

/* ✅ 10×10 layer = 400 bytes — then scale up on GPU */
.smart-layer {
  width: 10px;
  height: 10px;
  background: radial-gradient(circle, #ff6b6b, transparent);
  transform: scale(10);
  will-change: transform;
}

Both look identical. The second uses 100× less GPU memory.

This trick is especially powerful for decorative elements like glows, gradients, and blurred backgrounds. For images, even a 5–10% reduction in source size (compensated with scale) can meaningfully reduce memory on high-DPI screens.

6. Batch DOM reads and writes

Never interleave reads and writes:

// ❌ Forces Reflow on every iteration (layout thrashing)
items.forEach(item => {
  item.style.width = item.offsetWidth + 10 + 'px';
});

// ✅ All reads first, then all writes
const widths = items.map(item => item.offsetWidth);
items.forEach((item, i) => {
  item.style.width = widths[i] + 10 + 'px';
});

// ✅ Or batch changes via class toggle — one Reflow total
items.forEach(item => item.classList.add('expanded'));

Beyond the basics: modern CSS performance tools

The rendering pipeline hasn't changed, but browsers have added new CSS properties that give you explicit control over what gets rendered and when.

`contain` — opt out of cascading costs

By default, changing one element can force the browser to re-layout and re-paint large portions of the page. The contain property tells the browser: "this element's internals won't affect anything outside it."

.pricing-card {
  contain: layout paint;
  /* 
    layout — element's internals can't affect outside layout
    paint  — element's content won't be painted outside its box

    Now Reflow inside .pricing-card won't cascade 
    to siblings or parents.
  */
}

/* The strict shorthand: */
.widget {
  contain: strict;
  /* = contain: size layout paint style */
  /* Most aggressive — but requires explicit width/height */
}

This is especially powerful for repeated components like cards in a grid, list items, or dashboard widgets. If one card's content changes, only that card gets re-layouted.

`content-visibility: auto` — skip rendering off-screen content

This is one of the biggest rendering performance wins available today:

.section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px; /* estimated height for scrollbar */
}

content-visibility: auto tells the browser: "don't bother laying out, painting, or compositing this element until it's near the viewport." For long pages, this can skip rendering of entire sections until the user scrolls to them.

Real-world impact: Chrome's own testing showed rendering cost reductions of up to 7× on long pages — from 232ms down to 30ms rendering time.

How they fit into the pipeline

                                              What it skips:

  Layout ──► Paint ──► Composite

  contain: layout paint     ──► Limits Reflow/Repaint scope (doesn't cascade)
  content-visibility: auto  ──► Skips ALL stages for off-screen elements
  will-change: transform    ──► Pre-promotes to Composite layer
  transform / opacity       ──► Skips Layout and Paint entirely

Why this matters for Core Web Vitals

Everything in this article directly impacts Interaction to Next Paint (INP) — the Core Web Vital that measures how fast your page responds to user input.

Here's the connection: when a user clicks a button, the browser needs to run your JS handler, recalculate layout, repaint, and composite — all before the next frame. If your click handler triggers a massive Reflow (because of layout thrashing, deep DOM, or animating width instead of transform), the time from click to visual response spikes. That's a bad INP score.

Every optimization in this article — batching reads/writes, using contain to limit Reflow scope, keeping animations on the compositor thread — directly reduces INP by keeping the main thread free to process interactions quickly.

Debugging: see it with your own eyes

Theory is great. But you need to see what your browser is actually doing.

Remember the checkout page from the intro? Here's exactly how I found the problem:

Opened Web Inspector → Elements → Layers tab.
Saw 34 composite layers where I expected 3–4. Total memory: over 200 MB.
Clicked on a pricing card layer. Compositing reason: "has a composited descendant with a lower z-index." — implicit compositing.
Traced it back: an animated gradient background (@keyframes with transform) was sitting below all the pricing cards in z-index.
Every card above it got silently promoted to its own layer. Each card ~600×400 on 3× display = ~2.7 MB per card. Multiply by 12 cards, plus badges, plus decorative elements — 200 MB.
The fix: moved the animated background to z-index: -1 and removed two stale will-change: transform declarations from cards that no longer animated. 34 layers → 2. 200 MB → ~8 MB.

Three lines of CSS. Two minutes of work. But only because I knew where to look.

Chrome DevTools — Layers panel

Open DevTools first (F12 or Cmd+Option+I on Mac / Ctrl+Shift+I on PC), then Cmd+Shift+P (Mac) or Ctrl+Shift+P (PC) → type "Show Layers" → Enter.

This shows you every composite layer on the page: its size, memory consumption, and — most importantly — why it was created. If you see "compositing reason: has a composited descendant with a higher z-index" — that's implicit compositing.

Chrome DevTools — Rendering panel

With DevTools open, Cmd+Shift+P (Mac) or Ctrl+Shift+P (PC) → type "Show Rendering" → Enable:

Paint flashing — green rectangles flash wherever Repaint happens. If your "GPU animation" shows green flashes every frame, it's not running on GPU.
Layer borders — orange outlines show composite layers. If you see dozens of orange rectangles where you expected a few, you have implicit compositing.
Scrolling performance issues — highlights elements that slow down scrolling.

Chrome DevTools — Performance panel

Record a session → look at the flame chart:

Purple bars (Layout) in the "Main" section of the flame chart = you're triggering Reflow. Hover over them to see which element and which JS call caused it.
Green bars (Paint) on every frame = you're triggering Repaint. Click on a paint event to see the affected area.
Nothing but Composite = you're on the GPU fast path ✅
If you see "Forced reflow is a likely performance bottleneck" in yellow — that's layout thrashing. Click the warning to jump straight to the offending code.

Web Inspector — Layers tab

Elements panel → right sidebar → Layers. Shows composite layers with memory usage and compositing reasons. Often more readable than Chrome's panel for quick audits.

The cheat sheet

Cheapest ◄──────────────────────────────────────────► Most expensive

Composite only        Repaint only          Reflow + Repaint
(GPU, compositor      (CPU, main thread)    (CPU, main thread,
 thread)                                     cascades to children)

transform             color                 width / height
opacity               background            margin / padding
                      box-shadow            font-size / line-height
                      visibility            display / position
                      outline               top / left / right / bottom
                                            border / float / overflow

The rules I follow:

Animate only transform and opacity — @keyframes and transition are just delivery mechanisms; the property inside is what matters
Pick the right animation tool: transition for A→B, @keyframes for loops/multi-step, Element.animate() for JS-controlled, rAF as last resort
Keep animated elements high in z-index — implicit compositing is the #1 hidden cost
Never interleave DOM reads and writes — batch them to avoid layout thrashing
Use will-change as a scalpel, not a sledgehammer — apply before animation, remove after
Watch for Layer Squashing — if DevTools shows one giant merged layer, use unique translateZ values
Use contain on repeated components — cards, list items, widgets
Use content-visibility: auto on long scrollable content
Audit with Layers panel after every feature — especially on mobile
Keep DOM flat — deep nesting multiplies Reflow cost
Test on real mid-range devices — your MacBook Pro lies to you about INP, memory, and GPU

The browser rendering pipeline hasn't fundamentally changed in a decade. But the tools to control it have gotten dramatically better. The developers who understand these internals don't just write faster animations — they make better architectural decisions about how components are structured, how DOM is organized, and where performance budgets should go.

Understanding this stuff turned a 2-second freeze on my checkout page into a fix that took 3 lines of CSS. I hope it saves you a similar debugging session.

What rendering performance gotchas have you run into? I'd love to hear your war stories in the comments 👇

If you found this useful, I write about frontend architecture and performance regularly — follow for more deep dives.

You're Using 10% of SCSS. Here's What You're Missing.

Olexandr Uvarov — Thu, 05 Mar 2026 07:23:08 +0000

Let's be honest. Most SCSS files in most projects look like this:

$primary: #ff69b4;
$border-radius: 8px;

.card {
  color: $primary;
  border-radius: $border-radius;

  &__title {
    font-size: 18px;
  }
}

Variables. Nesting. Maybe a mixin or two. That's it.

Meanwhile, this is also SCSS — a music visualizer with 16 independently animated bars, over 1,600 generated keyframe declarations, and zero JavaScript:

That's ~30 lines of SCSS generating what would take hundreds of lines to write by hand. It uses features that most developers never touch: @for, random(), nested loops, dynamic @keyframes.

SCSS is a programming language. Let me show you the 90% you're probably not using.

Each — Iterate Over Data Structures

The problem: Typography styles are a set of properties that always go together — font-size, font-weight, line-height. You define 10 variants and write each one out manually. Add a property to a variant — hope you didn't miss a spot.

Store font styles as maps and apply them with a single mixin:

$body-16R: (
  'font-weight': 400,
  'font-size': 16px,
  'line-height': 1.6
);

$body-14R: (
  'font-weight': 400,
  'font-size': 14px,
  'line-height': 1.4
);

@mixin font-style($font-type, $color: null) {
  @each $key, $value in $font-type {
    #{$key}: $value;
  }
  color: $color;
}

.size {
  &14 {
    @include font-style($body-14R);
  }
  &16 {
    @include font-style($body-16R);
  }
}

The mixin doesn't care how many properties are in the map — it iterates over whatever you give it. Add letter-spacing to the map? The mixin picks it up automatically. No changes anywhere else.

Works great for generating design system tokens too:

$icon-sizes: (sm: 16px, md: 24px, lg: 32px, xl: 48px);

@each $name, $size in $icon-sizes {
  .icon-#{$name} {
    width: $size;
    height: $size;
  }
}

One map, one loop — four consistent icon classes. New size? Add one line to the map.

If / Else — Conditional Logic at Build Time

The problem: Large headings need tight line-height. Body text needs loose line-height. You set these manually everywhere and they inevitably drift out of sync.

Let the mixin decide automatically:

@mixin font-size($size) {
  font-size: $size;

  @if $size > 24px {
    line-height: 1.2;
  } @else if $size > 16px {
    line-height: 1.4;
  } @else {
    line-height: 1.6;
  }
}

h1 { @include font-size(36px); } // line-height: 1.2
h2 { @include font-size(22px); } // line-height: 1.4
p { @include font-size(16px); }  // line-height: 1.6

One rule, consistent typography across the entire project. The relationship between font-size and line-height is defined once — not scattered across 50 selectors.

Conditionals also help reduce mixin boilerplate. Here's one for pseudo-elements:

@mixin pseudo-element(
  $pseudo-element: before,
  $content: '',
  $position: relative,
  $display: block
) {
  @if ($pseudo-element == all) {
    &:after,
    &:before {
      position: $position;
      display: $display;
      content: $content;
      @content;
    }
  }
  @else {
    &:#{$pseudo-element} {
      position: $position;
      display: $display;
      content: $content;
      @content;
    }
  }
}

// Both pseudo-elements at once
.decorated {
  @include pseudo-element(all) {
    width: 10px;
    height: 10px;
    background-color: #a8efda;
  }
}

// Just ::after
.arrow {
  @include pseudo-element(after) {
    border: 5px solid transparent;
    border-top-color: #333;
  }
}

Pass all — get both. Pass before or after — get just one. The @content directive lets you inject custom styles. One flexible mixin instead of copy-pasting pseudo-element boilerplate.

Functions — Compute Values Instead of Hardcoding

The problem: Magic numbers. Why is the padding 24px? Because someone picked it. Now the design team wants tighter spacing — go find and replace through every file.

Define a spacing system as a function:

$base-spacing: 8px;

@function space($multiplier) {
  @return $base-spacing * $multiplier;
}

.card {
  padding: space(3);        // 24px
  margin-bottom: space(2);  // 16px
  gap: space(1.5);          // 12px
}

.modal {
  padding: space(4);        // 32px
  margin: space(6) auto;    // 48px auto
}

Every spacing value traces back to one base unit. Want to tighten the whole UI? Change $base-spacing from 8px to 6px — everything recalculates.

Another common pain point — px to rem conversion:

$root-font-size: 16px;

@function rem($px) {
  @return ($px / $root-font-size) * 1rem;
}

h1 { font-size: rem(32px); }    // 2rem
h2 { font-size: rem(24px); }    // 1.5rem
.small { font-size: rem(12px); } // 0.75rem

No more mental math. No more incorrect rem values from eyeballing the conversion. The function does it right every time, and if the root font size changes, every rem value stays correct.

Maps — Structured Data as a Single Source of Truth

The problem: Z-index chaos. One developer sets z-index: 999, another uses z-index: 9999 to go above it, a third adds z-index: 99999. Nobody knows the stacking order anymore.

Put it all in one map:

$z-layers: (
  dropdown: 100,
  sticky: 200,
  modal: 300,
  tooltip: 400,
  toast: 500,
);

.dropdown { z-index: map-get($z-layers, dropdown); }
.modal { z-index: map-get($z-layers, modal); }
.tooltip { z-index: map-get($z-layers, tooltip); }

The full stacking order visible at a glance. New layer needed? Add it to the map in the right position. No more z-index arms race.

Maps also support operations — merge, remove, lookup:

$sizes: (40: 40px, 50: 50px, 80: 80px);
$extra: (60: 60px);

// Compose data before generating CSS
$all-sizes: map-merge($sizes, $extra);
$final-sizes: map-remove($all-sizes, 40);

@each $size, $value in $final-sizes {
  .icon-#{$size} {
    width: $value;
    height: $value;
  }
}

You can build up, combine, and filter your data structures before generating any CSS from them. And map-has-key lets you check if a key exists before accessing it — defensive programming in your stylesheets:

$font-weights: ("regular": 400, "medium": 500);

.title {
  @if (map-has-key($font-weights, "bold")) {
    font-weight: map-get($font-weights, "bold");
  } @else {
    font-weight: map-get($font-weights, "medium"); // safe fallback
  }
}

For — Generate Numbered Sequences

The problem: You need a grid system. Writing .col-1 through .col-12 by hand is exactly the kind of work a loop should do.

$columns: 12;

@for $i from 1 through $columns {
  .col-#{$i} {
    width: percentage($i / $columns);
  }
}

12 classes from 4 lines. Need a 10-column grid? Change one number. This is the same principle behind every CSS framework's grid.

Loops really shine when math is involved. I built an analog clock entirely with SCSS — the face needs 30 tick divs, each with ::before and ::after pseudo-elements, giving 60 tick marks total. Each pair is rotated by exactly 6 degrees:

@for $i from 1 through 30
  .item__minute:nth-child(#{$i})
    $rotate: $i * 6deg
    transform: translate(-50%, -50%) rotate($rotate)

60 tick marks at precise angles from 4 lines. Every 5th marker gets a longer tick for hours via &:nth-child(5n). The clock hands are pure CSS @keyframes — JavaScript only calculates the starting position once, then CSS handles all movement.

The clock also uses the SCSS Maps + CSS Custom Properties pattern from my previous article — it has 4 time-based themes (morning, day, evening, night) that switch automatically based on the current hour. All theme tokens live in a single $modes map.

See the live demo → | Source code on GitHub

Staggered animations — another common use:

@for $i from 1 through 8 {
  .fade-in:nth-child(#{$i}) {
    animation-delay: $i * 0.1s;
  }
}

Each item fades in 100ms after the previous one. The pattern extends automatically.

How the Visualizer Works

Now you've seen all the building blocks, let's come back to that audio visualizer from the intro:

.wrap {
  height: 50px;
  overflow: hidden;
  display: flex;
  align-items: center;

  div {
    height: 100%;
    width: 4px;
    background-color: red;
    margin: 0 1px;
    border-radius: 4px;
    will-change: transform;
  }

  @for $i from 1 through 16 {
    div {
      &:nth-of-type(#{$i}) {
        animation: pulse-#{$i} 16s infinite ease-in-out;

        @keyframes pulse-#{$i} {
          $randomNumber: random(100) + 0%;

          0% {
            transform: translateY($randomNumber);
          }
          @for $step from 1 through 99 {
            #{$step + 0%} {
              $stepRandomNumber: random(100) + 0%;
              transform: translateY($stepRandomNumber);
            }
          }
          100% {
            transform: translateY($randomNumber);
          }
        }
      }
    }
  }
}

Every feature from this article is at work:

Outer for-loop — creates 16 bars with unique animations
Inner for-loop — generates 99 keyframe steps per animation
random() — gives each step a different translateY value
String interpolation — builds dynamic animation names and keyframe percentages

The compiled CSS: 16 animations × 100 steps = 1,600+ transform declarations. Since random() runs at compile time, every build produces a different animation pattern.

Play with it on CodePen →

Should You Use All of This?

The space() function, z-layers map, and @each typography mixin are everyday tools — use them tomorrow. The audio visualizer is an extreme example, but it shows the ceiling of what's possible when you treat SCSS as a real language.

Next time you're about to copy-paste a block and change one value, ask yourself — could a loop, a function, or a map handle this?

Stop writing CSS by hand when SCSS can generate it for you.

If you're curious how maps and CSS custom properties work together for runtime theming, I covered that in my previous article.

What SCSS features do you use beyond variables and nesting? Let me know in the comments.

SCSS Maps + CSS Custom Properties: Scalable Runtime Theming Without Duplication

Olexandr Uvarov — Thu, 19 Feb 2026 07:36:54 +0000

You're building a platform that serves different user segments — each with their own visual style. Maybe it's A/B testing different UIs, maybe it's a white-label product with per-client branding. You have 6 modes today: "Pink Big", "Blue Small", "Dark Compact" and so on. Next month the design team rewrites half of them.

How do you organize your styles so that adding or changing a mode doesn't mean editing every component file?

I've been exploring different approaches in a side project and landed on a pattern that combines the best of SCSS maps and CSS custom properties. Let me walk you through the journey.

The Problem

We need to:

Switch between multiple visual modes at runtime based on user config or API response
Keep the bundle size reasonable
Make it easy to add, remove, or modify modes without touching every component
Keep component styles readable

Let's say we have 6 modes and 30 components that depend on them. That's our scale. Let's explore three approaches.

Approach 1: Pure SCSS Maps + Mixin

SCSS maps let you store structured data — essentially objects in your stylesheets. The idea: define all modes in one place and use a mixin to apply them.

$modes: (
  pink-big: (
    color: #ff69b4,
    font-size: 32px,
    font-weight: 700,
  ),
  blue-small: (
    color: #4a90d9,
    font-size: 18px,
    font-weight: 400,
  ),
);

@mixin apply-modes($component) {
  @each $mode-name, $components in $modes {
    .mode-#{$mode-name} & {
      $styles: map-get($components, $component);
      @each $prop, $value in $styles {
        #{$prop}: $value;
      }
    }
  }
}

Usage looks clean:

.title {
  @include apply-modes(title);
}

.button {
  @include apply-modes(button);
}

The problem: bundle bloat

Look at what this compiles to:

.mode-pink-big .title {
  color: #ff69b4;
  font-size: 32px;
  font-weight: 700;
}
.mode-blue-small .title {
  color: #4a90d9;
  font-size: 18px;
  font-weight: 400;
}
.mode-pink-big .button {
  color: #ff69b4;
  font-size: 32px;
  font-weight: 700;
}
.mode-blue-small .button {
  color: #4a90d9;
  font-size: 32px;
  font-weight: 700;
}

Every component gets a full copy of every mode's styles. With 6 modes and 30 components, that's 180 style blocks. With just 2 modes and 30 components, that would be 60. The bundle grows as modes × components — and that adds up fast.

Approach 2: Pure CSS Custom Properties

CSS custom properties solve the duplication problem elegantly. Define variables once per mode, use them everywhere:

.mode-pink-big {
  --color-primary: #ff69b4;
  --fs-title: 32px;
  --fw-title: 700;
}

.mode-blue-small {
  --color-primary: #4a90d9;
  --fs-title: 18px;
  --fw-title: 400;
}

.title {
  color: var(--color-primary);
  font-size: var(--fs-title);
  font-weight: var(--fw-title);
}

.button {
  background: var(--color-primary);
}

The math changes completely: 6 mode definitions + 30 components = 36 blocks instead of 180. Bundle grows as modes + components.

Switching modes at runtime is just swapping a class:

function App() {
  const userMode = useUserMode(); // from API, config, etc.
  const className = `app mode-${userMode}`;

  // renders: app mode-pink-big, app mode-blue-small, etc.
  return React.createElement('div', { className }, Title(), Button());
}

The problem: maintenance at scale

With 6 modes, you're writing variable declarations by hand:

.mode-pink-big { --color-primary: #ff69b4; --fs-title: 32px; --fw-title: 700; }
.mode-blue-small { --color-primary: #4a90d9; --fs-title: 18px; --fw-title: 400; }
.mode-dark-compact { --color-primary: #bb86fc; --fs-title: 16px; --fw-title: 500; }
.mode-light-wide { --color-primary: #1a73e8; --fs-title: 28px; --fw-title: 600; }
/* ...and two more */

It's flat, scattered, and easy to forget a variable when adding a new mode. There's no single source of truth you can glance at and understand all your modes.

Approach 3: The Combo — SCSS Maps Generating CSS Custom Properties

Here's where it gets interesting. What if we use SCSS maps as a structured config and generate CSS custom properties from them automatically?

Step 1: Define modes as nested SCSS maps

$modes: (
  pink-big: (
    title: (color: #ff69b4, font-size: 32px, font-weight: 700),
    button: (background: #ff69b4, padding: 16px, border-radius: 12px),
  ),
  blue-small: (
    title: (color: #4a90d9, font-size: 18px, font-weight: 400),
    button: (background: #4a90d9, padding: 8px, border-radius: 4px),
  ),
  dark-compact: (
    title: (color: #bb86fc, font-size: 16px, font-weight: 500),
    button: (background: #bb86fc, padding: 6px, border-radius: 4px),
  ),
);

Everything in one place. You can see all modes, all components, all values at a glance.

Step 2: Generate CSS custom properties automatically

@each $mode-name, $components in $modes {
  .mode-#{$mode-name} {
    @each $component, $styles in $components {
      @each $prop, $value in $styles {
        --#{$component}-#{$prop}: #{$value};
      }
    }
  }
}

This compiles to:

.mode-pink-big {
  --title-color: #ff69b4;
  --title-font-size: 32px;
  --title-font-weight: 700;
  --button-background: #ff69b4;
  --button-padding: 16px;
  --button-border-radius: 12px;
}
.mode-blue-small {
  --title-color: #4a90d9;
  --title-font-size: 18px;
  /* ...etc */
}

Step 3: A mixin to wire components to their variables

Instead of manually writing var(--title-color), var(--title-font-size) for each property, let a mixin do it:

@mixin use-mode($component) {
  $first-mode: nth(map-values($modes), 1);
  $styles: map-get($first-mode, $component);

  @each $prop, $_ in $styles {
    #{$prop}: var(--#{$component}-#{$prop});
  }
}

Step 4: Use it

.title {
  @include use-mode(title);
  margin-bottom: 16px; // static styles work alongside
  text-transform: uppercase;
}

.button {
  @include use-mode(button);
  cursor: pointer;
}

This compiles to:

.title {
  color: var(--title-color);
  font-size: var(--title-font-size);
  font-weight: var(--title-font-weight);
  margin-bottom: 16px;
  text-transform: uppercase;
}

.button {
  background: var(--button-background);
  padding: var(--button-padding);
  border-radius: var(--button-border-radius);
  cursor: pointer;
}

One line to connect a component to its mode tokens. Static styles coexist naturally. No duplication.

Build-Time Validation

When someone adds a new mode but forgets a property, you want the build to fail — not the UI:

$required-keys: (
  title: (color, font-size, font-weight),
  button: (background, padding, border-radius),
);

@each $mode-name, $components in $modes {
  @each $component, $required in $required-keys {
    $styles: map-get($components, $component);
    @each $key in $required {
      @if not map-has-key($styles, $key) {
        @error "Mode '#{$mode-name}' → '#{$component}' is missing '#{$key}'";
      }
    }
  }
}

Add a mode with a missing font-weight? Build fails with:

Error: Mode 'new-mode' → 'title' is missing 'font-weight'

Much better than debugging a broken layout in production.

What About Dynamic Styles from a CMS?

So far we've assumed all modes are known at build time. But what if styles come from a CMS like Strapi, and you don't know the values until runtime?

The tempting (bad) approach

Fetch styles from the CMS and apply them directly to elements:

const tokens = await fetchStylesFromCMS();

document.querySelectorAll('.title').forEach(el => {
  el.style.color = tokens.titleColor;
  el.style.fontSize = tokens.titleFontSize;
  el.style.fontWeight = tokens.titleFontWeight;
});

Each el.style.* assignment can trigger a reflow. With 30 elements and 3 properties each, you're looking at up to 90 potential layout recalculations. Plus you lose the cascade, specificity becomes unpredictable, and debugging inline styles in DevTools is no fun.

The right approach: same CSS variables, different source

const tokens = await fetchStylesFromCMS();

Object.entries(tokens).forEach(([key, value]) => {
  document.documentElement.style.setProperty(`--${key}`, value);
});

One update on :root, browser recalculates the cascade once. Components don't care where the value came from.

The hybrid: build-time defaults + CMS overrides

This is where it gets practical. Your SCSS maps define sensible defaults per mode, and the CMS can override specific tokens at runtime:

// Build time — mode defaults baked in
.mode-pink-big {
  --title-color: #ff69b4;
  --title-font-size: 32px;
}

// Runtime — CMS overrides only what it needs
const cmsOverrides = await fetchStylesFromCMS();

if (cmsOverrides.titleColor) {
  document.documentElement.style.setProperty('--title-color', cmsOverrides.titleColor);
}
// If CMS sends nothing — mode default stays

The CSS cascade handles the priority naturally: inline custom properties on :root override class-based ones. Your component still just reads var(--title-color) — it doesn't know or care whether the value came from SCSS, a class, or JavaScript.

Why Not @extend?

You might think: "I'll use SCSS @extend with a placeholder for each mode." The problem is that @extend was designed to merge selectors in a global stylesheet:

// Global SCSS — @extend works as intended
%pink-title {
  color: #ff69b4;
  font-size: 32px;
}

.title { @extend %pink-title; }
.hero-title { @extend %pink-title; }

Compiles to one merged selector:

.title, .hero-title {
  color: #ff69b4;
  font-size: 32px;
}

But almost nobody writes global SCSS anymore. With CSS Modules — which is the standard in React/Next.js projects — @extend loses its superpower. CSS Modules scope each file independently, so there's no opportunity to merge selectors across modules. The result? @extend just copies the properties into each selector separately — exactly like a mixin, but with less control and more confusion. You get the same duplication problem from Approach 1, just with different syntax.

CSS custom properties don't have this issue. They cascade through scoped modules naturally — no cross-module dependencies needed.

Wrapping Up

The pattern is: SCSS maps as a structured config → CSS custom properties as the runtime mechanism. SCSS does the heavy lifting at build time (generating variables, validating completeness), and CSS custom properties handle the runtime switching with zero duplication.

It works for predefined modes, for CMS-driven styles, and for hybrids of both. Adding a mode is one entry in $modes. Adding a CMS override is one setProperty call. Components never need to change.

The trade-off is readability — @include use-mode(title) hides which properties a component receives. But when your modes change every month and you're tired of hunting down missed variables across 30 files, that trade-off pays for itself.

*What patterns do you use for runtime theming? I'd love to hear about different approaches in the comments.