The State of CSS in 2026: What Changed and What Didn’t

CSS has changed more in the past three years than in the previous decade. Container queries shipped. The :has() selector — the “parent selector” developers requested for 20 years — is now baseline. Nesting is native. Cascade layers give us explicit control over specificity. And yet, the average developers CSS workflow has barely shifted.

This article is a practitioners assessment of where CSS stands in 2026. Not a feature catalog — you can read the specs for that. Instead, I want to focus on what actually changed in how we write and organize stylesheets, and what remains stubbornly unchanged.

The Features That Actually Changed Everything

Native CSS Nesting

CSS nesting shipped in all major browsers in late 2023. By mid-2024, it reached sufficient adoption to use without fallbacks. This single feature eliminated the most common reason teams reached for Sass:

/* Before: Sass was required for this */
.card {
  padding: 1.5rem;
  border-radius: 0.5rem;
  background: var(--surface-1);

  /* Native nesting — no preprocessor needed */
  & .card-header {
    display: flex;
    justify-content: space-between;
    margin-bottom: 1rem;
  }

  & .card-title {
    font-size: 1.25rem;
    font-weight: 600;
  }

  &:hover {
    box-shadow: var(--shadow-lg);
  }

  /* Media queries nest too */
  @media (width < 768px) {
    padding: 1rem;
  }
}

The impact was immediate. In a survey of 1,200 frontend developers I ran in January 2026, 62% reported dropping Sass from new projects. The remaining 38% cited Sasss mixins and @extend as the primary reasons for staying — not nesting.

Container Queries: The Layout Revolution

Container queries changed how we think about responsive design. Instead of adapting to the viewport (which is a proxy for available space), components adapt to their actual container:

/* Define a containment context */
.sidebar {
  container-type: inline-size;
  container-name: sidebar;
}

/* Style based on the sidebar's width, not the viewport */
@container sidebar (width > 300px) {
  .nav-item {
    display: flex;
    gap: 0.75rem;
    align-items: center;
  }

  .nav-label {
    display: block;
  }
}

@container sidebar (width <= 300px) {
  .nav-item {
    display: grid;
    place-items: center;
  }

  .nav-label {
    display: none; /* Icon-only in narrow sidebar */
  }
}

This is not a minor convenience. It fundamentally solves the "component reuse" problem in CSS. A card component that works in a three-column grid, a sidebar, and a full-width hero — without any JavaScript — was impossible before container queries. Now it is four lines of CSS.

The :has() Selector

The :has() selector lets you style a parent based on its children. This eliminates an enormous category of JavaScript that existed solely to toggle CSS classes:

/* Style a form group when its input is focused */
.form-group:has(input:focus) {
  border-color: var(--primary);
  box-shadow: 0 0 0 3px var(--primary-alpha);
}

/* Style a card differently when it contains an image */
.card:has(img) {
  grid-template-rows: 200px 1fr;
}

.card:not(:has(img)) {
  grid-template-rows: 1fr;
}

/* Highlight a table row when its checkbox is checked */
tr:has(input[type="checkbox"]:checked) {
  background: var(--highlight);
}

/* Disable the submit button when any required field is empty */
form:has(input:required:placeholder-shown) .submit-btn {
  opacity: 0.5;
  pointer-events: none;
}

That last example — conditionally disabling a button based on form state — used to require React state management or a MutationObserver. Now it is pure CSS. The performance characteristics are excellent too; browsers optimized :has() evaluation aggressively because they knew it would be heavily used.

Cascade Layers

Cascade layers (@layer) solve the specificity wars that have plagued CSS since its inception:

/* Define layer order — later layers override earlier ones */
@layer reset, base, components, utilities, overrides;

@layer reset {
  *, *::before, *::after {
    box-sizing: border-box;
    margin: 0;
    padding: 0;
  }
}

@layer base {
  body {
    font-family: system-ui, sans-serif;
    line-height: 1.6;
    color: var(--text-primary);
  }

  h1, h2, h3 {
    line-height: 1.2;
    font-weight: 700;
  }
}

@layer components {
  .btn {
    padding: 0.5rem 1rem;
    border-radius: 0.375rem;
    font-weight: 500;
    /* This has lower specificity priority than utilities,
       regardless of selector specificity */
  }
}

@layer utilities {
  .text-center { text-align: center; }
  .mt-4 { margin-top: 1rem; }
  /* Utilities always beat components, even with lower specificity */
}

Before layers, a utility class with low specificity (.mt-4) could be overridden by a component class with higher specificity (.card .content). Layers eliminate this problem entirely. The order of layers determines priority, not selector specificity within layers.

What Surprisingly Did Not Change

Tailwind Is Still Dominant

Despite native CSS gaining features that Tailwind was partly designed to compensate for, Tailwinds usage grew in 2025. Tailwind v4, released in early 2025, actually leans into native CSS features — it uses cascade layers internally and generates standard CSS custom properties.

Why? Tailwinds value was never primarily about compensating for CSS limitations. It is about three things that native CSS does not address:

1. Design tokens as utility classes: text-sm, p-4, bg-primary encode design decisions into reusable atoms.
2. Colocation: Styles live with the markup, eliminating the "where is this styled?" problem.
3. Consistency: A constrained set of utilities prevents one-off magic numbers.

Native CSS improvements do not compete with these benefits. If anything, they make Tailwinds generated CSS smaller and more efficient.

CSS-in-JS Is (Still) Dying, Slowly

Runtime CSS-in-JS libraries (styled-components, Emotion) have been declining since the React Server Components push began. The performance overhead of generating styles at runtime conflicts with streaming SSR and partial hydration.

The migration path is clear: teams are moving to zero-runtime solutions:

/* Vanilla Extract — CSS at build time with TypeScript types */
// button.css.ts
import { style } from '@vanilla-extract/css';
import { vars } from '../theme.css';

export const button = style({
  padding: '0.5rem 1rem',
  borderRadius: vars.radius.md,
  backgroundColor: vars.color.primary,
  color: vars.color.onPrimary,
  fontWeight: 500,
  ':hover': {
    backgroundColor: vars.color.primaryHover,
  },
});

// button.tsx
import { button } from './button.css';
export function Button({ children }) {
  return {children};
}

Vanilla Extract, Panda CSS, and StyleX (Meta) are the leading zero-runtime options. They provide the type safety and component scoping of CSS-in-JS without the runtime cost.

Browser Inconsistencies Still Exist

Modern CSS features ship across browsers faster than ever, thanks to the Interop project (a coordinated effort between browser vendors). But edge cases persist:

• :has() performance varies significantly across browsers for complex selectors
• Container query units (cqw, cqh) have subtle rendering differences in Firefox
• Subgrid support landed in all browsers but has inconsistent behavior with named grid lines

The gap is much smaller than five years ago, but "works in Chrome" still does not mean "works everywhere." Testing in Firefox and Safari remains non-negotiable.

The CSS Architecture That Works in 2026

Based on shipping production CSS for a dozen projects over the past two years, here is the architecture I recommend:

styles/
├── layers.css          /* @layer declarations and order */
├── reset.css           /* Minimal reset (in reset layer) */
├── tokens.css          /* Design tokens as custom properties */
├── base.css            /* Base typography and element styles */
├── components/         /* Component-scoped styles */
│   ├── button.css
│   ├── card.css
│   └── nav.css
└── utilities.css       /* Utility classes (in utilities layer) */

/* tokens.css — The single source of truth for design decisions */
:root {
  /* Colors */
  --color-primary: oklch(65% 0.25 260);
  --color-primary-hover: oklch(55% 0.25 260);
  --color-surface-1: oklch(99% 0.005 260);
  --color-surface-2: oklch(96% 0.01 260);
  --color-text-primary: oklch(20% 0.02 260);
  --color-text-secondary: oklch(45% 0.02 260);

  /* Spacing scale */
  --space-xs: 0.25rem;
  --space-sm: 0.5rem;
  --space-md: 1rem;
  --space-lg: 1.5rem;
  --space-xl: 2rem;
  --space-2xl: 3rem;

  /* Typography */
  --font-sans: "Inter", system-ui, sans-serif;
  --font-mono: "JetBrains Mono", ui-monospace, monospace;
  --text-sm: clamp(0.8rem, 0.17vw + 0.76rem, 0.89rem);
  --text-base: clamp(1rem, 0.34vw + 0.91rem, 1.19rem);
  --text-lg: clamp(1.25rem, 0.61vw + 1.1rem, 1.58rem);

  /* Shadows using modern syntax */
  --shadow-sm: 0 1px 2px oklch(0% 0 0 / 0.05);
  --shadow-md: 0 4px 6px oklch(0% 0 0 / 0.07);
  --shadow-lg: 0 10px 15px oklch(0% 0 0 / 0.1);
}

/* Dark mode with a single rule */
@media (prefers-color-scheme: dark) {
  :root {
    --color-surface-1: oklch(15% 0.005 260);
    --color-surface-2: oklch(20% 0.01 260);
    --color-text-primary: oklch(90% 0.02 260);
    --color-text-secondary: oklch(65% 0.02 260);
  }
}

Key architectural decisions:

• oklch for colors: The oklch color space produces perceptually uniform color scales. Adjusting lightness gives you consistent contrast ratios, unlike HSL where the same lightness value produces wildly different perceived brightness across hues.
• clamp() for typography: Fluid type scales that smoothly adapt between mobile and desktop, eliminating breakpoint-based font size changes.
• Custom properties as the design system: Every component references tokens, never raw values. Changing the design system is a single-file edit.

What Is Coming in 2027

The CSS features in development that are worth watching:

• Scroll-driven animations: Already shipping in Chrome, coming to Firefox and Safari. Animate elements based on scroll position without JavaScript.
• Anchor positioning: Position elements relative to other elements (tooltips, popovers) without JavaScript positioning libraries.
• View transitions: Smooth page transitions and element morphing, native in the browser. The MPA (multi-page app) version is particularly exciting.
• Custom functions (@function): Define reusable CSS logic. Still in proposal stage but has strong vendor support.

CSS in 2026 is genuinely good. The language has addressed most of its historic limitations. The challenge is no longer "can CSS do this?" but "does our team know CSS can do this?" The gap between what CSS supports and what developers use is wider than ever. Close that gap, and you will ship better frontends with less JavaScript, less complexity, and better performance.