🎨 State of CSS 2026: The Feature Everyone Wants Is the One Nobody Can Ship

July 29, 2026 · 11 min read

Frontend Architect

banner

The State of CSS 2026 results are out, fielded May 15 – June 29, 2026 with ~4,900 respondents. The question set shrank from 63 features to 46, and the headline is a contradiction: the most-wanted new feature of the year is also the most-avoided one. Underneath that sits something stranger — CSS is the one part of the frontend stack AI still can't write. This post is about what to do differently, not about what the charts say.

note

The survey site reports two different numbers: 4,902 respondents on the metadata page, and "reached 5,506 developers" on the demographics page. The most likely explanation is completed responses vs. total starts, but the site doesn't say. We use the 4,902 figure throughout.

`position-anchor` is the story of the year — and you still can't ship it

Anchor positioning is the #1 favourite new feature developers started using this year at 18%, up four ranks, ahead of :has() at 17%. It also posted the largest year-over-year usage increase of any feature, +15%. On that same usage page it is the #1 feature developers avoid because of browser support, at 19%.

The most-adopted new feature of 2026 is also the most-blocked feature of 2026. That is not a paradox; it is what a feature looks like halfway through shipping. webstatus.dev puts anchor positioning at Baseline Limited availability with 230 developer upvotes, Mozilla marked positive and Apple marked support. It is also a named Interop 2026 focus area. The community has voted, the vendors have agreed, and only the calendar hasn't caught up.

So ship it the way you'd ship any Limited-availability feature: gated, with a real fallback.

anchor-positioning-progressive.css
.tooltip {
  /* Fallback that works everywhere today */
  position: absolute;
  top: 100%;
  left: 0;
}

@supports (anchor-name: --trigger) {
  .trigger { anchor-name: --trigger; }

  .tooltip {
    position: absolute;
    position-anchor: --trigger;
    position-area: block-end span-inline-end;
    position-try-fallbacks: flip-block, flip-inline;
    top: auto;
    left: auto;
  }
}

The @supports gate is the entire difference between "we're waiting on Baseline" and "we shipped it in Q3". The fallback branch is the part people skip, and it's the part that decides whether the 19% blocker applies to you.

The boring features still win

The top of the usage chart is not where the excitement is. It's where the work is.

Feature	Used	Positive	Baseline since
`:has()`	83.7%	51.8%	2023-12-19
`aspect-ratio`	81.3%	48.1%	—
CSS Nesting	70.6%	48.6%	2023-12-11
`scroll-behavior`	68.2%	—	—
Viewport-relative units	59.8%	—	—

Set that against the cross-feature averages: 31% used, 41% positive, 3% negative. The top of this table runs two to three times the mean, and the thing those features share is not elegance — it's that all five have been Widely available for years — the newest two since December 2023.

Usage tracks Baseline age almost perfectly. Treat that as a planning input rather than trivia: if you want to know what your team will actually be writing in 2028, look at what reaches Widely available in 2026.

The bottom of the table is Limited availability — and perception lags reality

The least-used features are gap decorations at 3.7%, if() at 4.9%, and container scroll-state queries at 5.5%. None of that is surprising. if() ships in Chrome and Edge 137 only and has 89 upvotes on webstatus.dev. Scroll-driven animations landed in Chrome 115 and Safari 26, and Firefox still hasn't shipped them.

The interesting case is View Transitions. It became Baseline Newly available on 2025-10-14 when Firefox 144 completed the set — and it is still the #2 most-avoided feature on browser-support grounds, at 9%. Developers are avoiding a feature that already works everywhere.

That gap is a process failure, not a knowledge failure. The likeliest explanation — ours, not the survey's — is that View Transitions landed on internal "don't use" lists before Firefox shipped, and nobody revisited them. Re-check that list against webstatus.dev once a quarter; it takes twenty minutes and it's the cheapest capability upgrade available to a frontend team. Our requirement engineering guide covers where Baseline checks belong in the intake process.

CSS is the last thing AI can't write

On average, 28% of respondents' CSS is AI-generated, and 26% generate none of it with AI at all. Survey co-author Sacha Greif notes that this chart "looks completely different" from the equivalent charts in State of AI 2026 and State of JS 2025, with respondent comments landing on the same explanation: "AI just isn't great at producing good CSS code yet".

Compare that to what we wrote up in State of Web Dev AI 2026, where AI adoption is close to universal. CSS is the only major layer of the stack where a quarter of professionals opt out of AI entirely.

Our hypothesis — this is opinion, not survey data — is that CSS lacks a cheap verification loop. JavaScript and TypeScript output either compiles and passes tests or it doesn't, and a model can close that loop by itself. CSS output is judged visually, by a human, against an intent that was never written down. There's no compiler error for "the spacing feels wrong". Until that loop exists, CSS stays hand-written.

The pain is cognitive, not technical

The general pain points are led by cognitive overload at 22%, then browser vendor issues at 20%, tooling at 13%, maintenance at 9% (up 18 ranks), and education at 9%. The per-area breakdowns say the same thing in different words. Layout: Grid 31%, browser vendor issues 17%, Flexbox 16% (up four ranks — Flexbox, in 2026), element sizing 13% (up nineteen ranks). Interactions: animations 28%, browser vendor issues 28%, CSS Carousels 9% (up eight).

Only 8% of respondents say they've learned about and tried most new features; 14% say they've done neither for most of them.

And yet happiness with CSS sits at 4 out of 5 and is still rising, above the 3.8 developers give web technology generally. People like CSS more than ever and understand less of it than ever.

Colors are their own microcosm: accessibility is the #1 pain point at 27%, theming second at 24%, and Wide Gamut Colors is the single most-disliked feature in the survey at 7.9% negative. We were fairly enthusiastic about that in High Definition CSS Colors; the enthusiasm has aged unevenly.

The abstraction layer is collapsing

CSS framework	Usage
Tailwind CSS	50%
None	28% (+1)
Bootstrap	27%
shadcn/ui	22%
Custom / in-house	19%
Material UI	19% (+8)

Parenthetical figures are rank movements, not percentage-point changes.

CSS-in-JS	Usage
None	59%
CSS Modules	26%
Styled Components	22%
Emotion	9%
Styled JSX	8%
vanilla-extract / Panda / StyleX / Pigment CSS	all below the named entries

Pre/post-processor	Usage
Sass / SCSS	56%
PostCSS	35%
None	25%
Lightning CSS	10% (+1)
Less	8%
Stylus	trailing the list

The trend line isn't Tailwind's 50%. It's "None" at 28% for frameworks and 59% for CSS-in-JS. The survey authors put it plainly: "The biggest threat to Tailwind's crown may not be another CSS framework, but simply no framework at all." On CSS-in-JS they're blunter: "Its era may be over."

Their call on preprocessors — "pre-processor usage is declining and may soon be a thing of the past" — is directionally right but worth tempering: 56% is still a majority. This is a decade-long tail, not a cliff. Utilities are stable and boring, which is correct: Prettier 70%, ESLint 65% (+9), Stylelint 31%, Biome 14% (+2).

Our own guidance on Tailwind, shadcn/ui, and MUI lines up with the top of that first table.

caution

shadcn/ui and Material UI are counted inside the CSS frameworks question, alongside Tailwind and Bootstrap. That's an odd taxonomy — a component library and a utility framework answer different questions — so don't read those rows as head-to-head competition. Base UI isn't broken out in the published framework results, so the survey says nothing about it either way.

The testing gap

Everyone tests on desktop: 100%. Smartphone is 66% and tablet 42%. Then it falls off a cliff — keyboard-only testing 34%, accessibility tooling 28%, screen readers 21%. Put that next to accessibility being the #1 colors pain point at 27% and the picture is a profession that knows a11y matters and mostly doesn't test for it.

Browser coverage has the same shape. Developers use Chrome 72%, Firefox 52%, Safari 25%, Safari iOS 16% — and "Safari issues" is the #4 named browser-support blocker. That's not a Safari bug rate; that's what 25% desktop and 16% mobile Safari testing produces.

A keyboard-only pass costs nothing. No tooling, no license, no setup — tab through the flow you just built. Two-thirds of the industry isn't doing it.

What developers still want

The #1 thing missing from CSS altogether is mixins, at 9% — after twenty years of preprocessors, and while preprocessor usage declines. @function exists now; mixins don't. Behind it: :has() improvements, if(), anchor positioning, media query variables, and form element styling. Masonry dropped five ranks, with demand migrating to display: grid-lanes.

The reading list follows the same logic — these are people saying they want to learn the feature, not ship it: gap decorations 54%, grid lanes 52%, calc-size() 51%, contrast-color() 49%. Awareness is climbing fastest for sibling-index() / sibling-count(), up 23% on the awards page (the homepage stat card says 22% — the site is inconsistent, and nothing here depends on which is right), and @function at +22%.

Here's the part worth internalising: Interop 2026 explicitly states that its focus areas were drawn from the State of HTML and State of CSS surveys. Anchor positioning is in this survey's complaint column and in Interop's work column. Filling in this survey is the highest-leverage twenty minutes a frontend developer spends on browser vendors all year. @container size queries gained +11% usage year over year — see our container queries doc — and that's what the pipeline looks like when it works.

What to do Monday

Adopt now — :has(), nesting, aspect-ratio, container queries, subgrid, view transitions. Yes, view transitions: it's Baseline Newly available and your team's mental model is out of date.

Ship behind @supports — anchor positioning, contrast-color() (Interop 2026 focus area — check webstatus.dev before committing), scroll-driven animations (still no Firefox).

Read but don't ship — if(), gap decorations, grid lanes, container scroll-state queries.

Process changes — put a quarterly Baseline audit on the calendar, add a keyboard-only pass to your definition of done, and stop assuming AI is quietly covering your CSS review load. It isn't.

tip

Make the Baseline audit a recurring calendar item with a named owner. Open webstatus.dev, diff it against your internal "don't use" list, delete the entries that are now Widely or Newly available. Our Baseline doc explains what the availability tiers mean and how to read them. View Transitions being the #2 avoided feature is what happens when nobody owns that list.

position-anchor is the story of the year — and you still can't ship it​

The boring features still win​

The bottom of the table is Limited availability — and perception lags reality​

CSS is the last thing AI can't write​

The pain is cognitive, not technical​

The abstraction layer is collapsing​

The testing gap​

What developers still want​

What to do Monday​

Further reading​