CSS in 2026: What Still Matters and What You Can Finally Stop Doing

CSS has changed more in the last four years than in the previous fifteen. If your stylesheets still open with a reset full of float clears and vendor prefixes for browsers nobody uses, you are carrying weight you do not need. Here is what actually matters now, and what you can safely delete.

Container queries replaced most of your media query gymnastics

Media queries ask about the viewport. Container queries ask about the parent element. That distinction sounds small until you build a card component that lives in a wide sidebar on one page and a narrow grid cell on another. Before container queries, you either wrote modifier classes or duplicated CSS.

Now you mark the parent as a container and query it directly:

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

.card {
 display: grid;
 gap: 1rem;
}

@container card (min-width: 400px) {
 .card {
 grid-template-columns: 120px 1fr;
 align-items: center;
 }
}

The card restyles based on the space it actually has, not the size of the browser window. This is the single biggest shift in how I write component CSS. If you are still adding .card--horizontal modifier classes purely to handle layout differences at different widths, container queries will delete that class and the JavaScript or template logic that toggles it.

Browser support is solid across Chrome, Safari, and Firefox. You do not need a polyfill in 2026.

:has() is the parent selector we waited twenty years for

For most of my career, “you can’t select a parent in CSS” was a rule you learned in week one. That rule is dead. :has() shipped everywhere and it is stable.

The practical wins are everywhere. Form field styling based on validation state, cards that change layout when they contain an image, navigation that highlights a section when a child link is active:

/* Style the label when its input is invalid */
.field:has(input:user-invalid) label {
 color: #b3261e;
}

/* Card with an image gets a different padding rhythm */
.card:has(img) {
 padding: 0;
}

/* Nav item stays highlighted while any child link is active */
.nav-item:has(a[aria-current="page"]) {
 border-bottom: 2px solid currentColor;
}

That last one replaces a chunk of JavaScript I used to write for every site with anchor-link navigation. Fewer moving parts, less to break.

Cascade layers end the specificity arms race

If you have ever written !important at 11pm to beat a framework, cascade layers are for you. @layer lets you declare the order your styles resolve in, independent of selector specificity.

@layer reset, base, components, utilities;

@layer base {
 a { color: navy; }
}

@layer utilities {
 .text-red { color: crimson; }
}

Even though a and .text-red have different specificity, the layer order wins. Utilities beat components beat base. No !important, no specificity counting, no guessing why a style is not applying. When I audit a legacy site that has grown into thousands of lines of competing rules, layers are usually the cleanest path back to something maintainable.

What you can finally delete

• Float-based layouts. Flexbox and Grid handle every case floats were hacked into. Floats are for wrapping text around an image again.
• Clearfix hacks. If you removed the floats, you removed the need.
• Most vendor prefixes. Autoprefixer and browsers have caught up. Prefixes for border-radius and box-shadow are dead weight.
• Separate stylesheets per breakpoint. One file with container queries beats five files you have to keep in sync.
• JavaScript for layout. Measuring element widths in JS and toggling classes is almost always a container query now.

What is still worth your attention

A few things I would not skip:

• Logical properties. Use margin-inline and padding-block instead of left/right/top/bottom. It costs nothing and makes internationalization trivial.
• Color functions. oklch() gives you perceptually even color scales, which makes building a palette far less painful than fighting with HSL.
• clamp() for fluid type. One line replaces a pile of media queries for font sizing.

h1 {
 font-size: clamp(1.75rem, 1rem + 3vw, 3.5rem);
 color: oklch(0.35 0.12 250);
}

Where this lands for real projects

Every site I touch, whether it is a small business brochure site or a web app, gets the same treatment now: layers for order, container queries for components, :has() for state, and a hard pass on anything that exists only to satisfy a browser from 2014. If you are working with a designer or developer on a rebuild and want to know what a modern stylesheet should look like, this is the short version. I do a lot of this work for small businesses around Long Island web design, and the cleanup is usually the same story: less code, fewer bugs, faster pages.

FAQ

Do I need to rewrite my whole stylesheet to use these?

No. Start with layers, since that is a five-minute change that immediately makes the rest easier to reason about. Add container queries to new components as you build them. You can leave old CSS alone until you touch it.

Is container query support good enough to rely on?

Yes. Container queries and :has() are supported in all current major browsers. The only reason to avoid them is if you must support a browser that stopped receiving updates years ago.

Will any of this break my existing site?

Layers can change which rule wins, so audit your !important usage before adopting them. The other features are additive. You can introduce them without touching existing rules, which is exactly why I recommend that order.