Modern CSS in 2026: What Still Matters and What You Can Drop

Most CSS advice you find online was written for a browser landscape that no longer exists. If you’re still reaching for float-based layouts, vendor prefixes by muscle memory, or a preprocessor just to nest selectors, you’re doing extra work for no reason. Here’s what actually changed, what it means for real projects, and the code you can use today.

Container queries are the biggest shift since flexbox

Media queries ask “how wide is the viewport?” Container queries ask “how wide is the thing I’m inside?” That distinction matters more than it sounds. A card component should look right in a wide sidebar and a narrow grid column, and viewport width tells you nothing about either case.

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

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

Support has been solid across all major browsers for a while now, so this is not a “progressive enhancement someday” feature anymore. If you’re building a design system in 2026, container queries should be your default for component-level responsiveness. Reserve media queries for page-level layout decisions.

Naming containers saves you grief

Once you have nested containers, unnamed queries get ambiguous. Give them names. It costs nothing and makes debugging far easier when a component sits inside three other containers.

:has() finally killed most of the JavaScript you wrote for parent selection

The :has() selector lets you style a parent based on its children. For years this required a script, a class toggle, or a data attribute you had to keep in sync. Now it’s just CSS.

/* Style the form group only when the input is invalid */
.form-group:has(input:user-invalid) {
 border-color: #c0392b;
}

.form-group:has(input:user-invalid) .hint {
 display: block;
 color: #c0392b;
}

/* Add spacing only when a card actually has an image */
.card:has(> img) {
 padding-top: 0;
}

One honest caveat: :has() can hurt performance if you use it in a way that forces the browser to re-evaluate large parts of the tree on every DOM change. Keep selectors scoped and avoid chaining it deep. Used sensibly, it’s fine.

Native nesting is here, with one gotcha

CSS nesting works in every current browser. You no longer need Sass or Less for basic nesting, which means one less build step and one less dependency to maintain.

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

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

 &:hover {
 background: #f5f5f5;
 }
}

The gotcha: nesting with bare element selectors like & a is fine, but nesting a selector that starts with a letter (like .foo .bar) requires & to avoid the browser parsing it as a nested property. If you’re porting Sass, watch for that.

You probably still want a preprocessor for other reasons

Nesting alone isn’t a reason to keep Sass. Mixins, loops, and functions still aren’t in plain CSS (though @function and @mixin are landing in some engines). If you only used Sass for nesting and variables, you can drop it. If you lean on mixins heavily, keep it or move to a build tool that handles those needs.

Things you can stop doing

• Vendor prefixes by hand. Use autoprefixer or your bundler’s built-in handling. Writing -webkit- manually in 2026 is busywork.
• Float-based grids. Use Grid and Flexbox. Floats are for text wrapping around images, which is what they were designed for.
• Clearfix hacks. If you’re still writing .clearfix::after, you’re maintaining a layout that shouldn’t exist.
• Pixel-perfect breakpoint ladders. Design components to respond to their container, not to a list of 12 device widths someone guessed at in 2015.

Modern color and the new syntax

You can now define colors in ways that adapt without JavaScript. oklch() gives you perceptually uniform color, which means lightening a color doesn’t wash it out the way HSL does.

:root {
 --brand: oklch(60% 0.18 250);
 --brand-light: oklch(85% 0.08 250);
}

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

.button:hover {
 background: oklch(from var(--brand) calc(l + 0.1) c h);
}

That relative color syntax lets you derive shades from a single source of truth. It’s supported widely enough now that you can use it in production, though test on your target browsers if you support anything old.

What this means for a small business site

If you’re running a brochure site or a small storefront, you don’t need most of this. What you do need is a stylesheet that loads fast, renders predictably, and doesn’t break when someone updates a plugin. That’s a different problem than “which CSS features are cool in 2026.”

I’ve been building sites for businesses around Commack and across Long Island for years, and the pattern holds: the sites that age well are the ones with simple, well-organized CSS and no framework churn. If you’re weighing a rebuild versus a cleanup, it’s usually worth talking through what you actually have before ripping anything out. You can see how I approach that kind of work over at my Long Island web design page.

FAQ

Do I still need Sass or Less in 2026?

Only if you rely on mixins, loops, or functions. If you used it mainly for nesting and variables, plain CSS handles both now and you can drop the build step.

Is :has() safe to use in production?

Yes, it’s supported in all current browsers. Just keep the selectors scoped and avoid chaining it deeply, since it can affect rendering performance on large DOM trees.

Should I rewrite my old CSS to use container queries?

Not wholesale. Migrate component by component as you touch them. A full rewrite is rarely worth it unless the existing CSS is genuinely unmaintainable.