6 Modern CSS Features That Are Finally Safe to Use in 2026 (and What Each One Replaces)

A CSS feature is safe to use when it reaches Baseline Widely available, meaning it has been supported in every major browser engine for at least 30 months. Several features that spent years in the "someday" pile crossed that line recently, and a few more hit Baseline Newly available in 2026. Here are the six I have actually changed my code because of, and what each one lets you delete.

1. The :has() selector

The :has() selector styles an element based on what it contains. It reached Baseline Widely available in June 2026, and it was the most-named favorite new feature in the State of CSS 2025 survey.

What it replaces is a specific and very common piece of JavaScript: the code that adds a class to a parent because of something about its children.

/* Card that looks different when it actually contains an image */
.card:has(img) {
  grid-template-columns: 120px 1fr;
}

/* Form field that reacts to its own input being invalid */
.field:has(input:invalid) {
  border-color: crimson;
}

/* Style a label based on a sibling checkbox, no wrapper class needed */
label:has(+ input:checked) {
  font-weight: 600;
}

I removed about forty lines of DOM-watching JavaScript from a form component with the second rule above. That is the pattern: anywhere you have a MutationObserver or an onChange handler whose only job is toggling a class, :has() probably replaces it.

2. Container queries

Container queries let a component respond to the width of its container rather than the width of the viewport. They have been Baseline Widely available since August 2025, with support in every major browser released since 2023, sitting around 92.6% global support.

This is the one that actually changes how you write components. A media query asks about the browser window, which a reusable component has no business caring about. A container query asks about the space the component was given.

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

@container card (min-width: 400px) {
  .card {
    display: grid;
    grid-template-columns: 1fr 2fr;
  }
}

Drop that card in a narrow sidebar and it stacks. Drop the same card in a wide main column and it goes side by side. No props, no variants, no wrapper classes describing where the component happens to be.

Worth being honest about the limits, though. Container queries do not solve everything people hoped. You still need a container element separate from the thing being styled, because an element cannot query itself without creating a circular dependency. That extra wrapper is mildly annoying and there is no way around it.

3. Container style queries

Style queries are the newer sibling and let CSS respond to the value of a custom property on an ancestor. They reached Baseline Newly available in 2026 when Firefox 151 shipped style() query support for custom properties.

.panel { --tone: neutral; }
.panel.is-warning { --tone: warning; }

@container style(--tone: warning) {
  .panel-title { color: #7a4a12; }
  .panel-icon { display: block; }
}

Newly available means it works everywhere current but has not had the 30 month soak. I would use it with a sensible fallback rather than as load-bearing layout logic today.

4. Native CSS nesting

Nesting lets you write child and state rules inside a parent rule without a preprocessor. For a lot of projects this removes the last real reason Sass was in the build at all.

.nav {
  display: flex;
  gap: 1rem;

  & a {
    color: inherit;
    text-decoration: none;

    &:hover { text-decoration: underline; }
  }

  @media (width < 640px) {
    flex-direction: column;
  }
}

One caution from experience: native nesting makes it very easy to write deeply nested rules with specificity that fights you later. Preprocessors had the same trap and the same discipline applies. Two levels is usually plenty.

5. The View Transitions API

View transitions animate between two states of a page, including across full page navigations. Same-document transitions ship in Chromium from Chrome 111, WebKit from Safari 18, and Gecko from Firefox 144. Cross-document transitions, the ones that work on a traditional multi-page site, are supported in Chromium browsers since Chrome 126 and Safari 18.2, with Firefox support in progress.

For a same-document change, the entire API is one function:

document.startViewTransition(() => {
  updateTheDom();
});

For cross-document, there is no function to call at all. Both pages opt in through CSS and the browser handles the rest:

@view-transition {
  navigation: auto;
}

That second one genuinely surprised me the first time. A static multi-page site gets app-like transitions from two lines of CSS and no JavaScript framework.

6. Modern range syntax in media queries

A small one, but it removes a persistent source of off-by-one bugs. Instead of min-width and max-width with their inclusive and exclusive edge cases, you write actual comparisons:

/* Old */
@media (min-width: 640px) and (max-width: 1023.98px) { }

/* New */
@media (640px <= width < 1024px) { }

The .98 pixel hack existed purely because max-width is inclusive and there was no way to express "up to but not including." That whole class of workaround is gone.

What I would adopt first

If you only pick up one thing from this list, make it :has(). It has the highest ratio of JavaScript deleted to CSS learned, and it is now widely available rather than newly available, so there is no real risk in leaning on it.

Container queries are the bigger long-term shift, but they change how you architect components rather than how you write a rule, so they are worth adopting on a new component rather than retrofitting across an existing design system in one pass. I tried the retrofit approach on an old project and abandoned it halfway through. Doing it component by component as you touch things works much better.

Reference: web.dev Baseline for current status on any of these, and MDN's CSS reference for syntax details.