Forem: Effeilo

Normalize.css Is Dead. Here's What to Use Instead.

Effeilo — Sat, 04 Apr 2026 14:40:31 +0000

Not just a reset. A browser upgrade.

Normalize.css was a landmark project. For years, it was the go-to starting point for web projects: a reliable, well-documented file that ironed out browser inconsistencies without erasing everything like a CSS reset would.

But normalize.css is no longer maintained. The last commit was in 2019. The browsers it was written for have moved on. And the web has moved on with them.

So what should you use instead in 2026?

What Normalize.css Actually Did

Normalize.css had a clear, singular goal: make browsers render HTML elements consistently, without removing styles that are useful by default.

It preserved heading sizes, list markers, and form element rendering. It fixed known browser bugs. It was deliberately minimal and unopinionated.

That philosophy was sound. But it left a lot on the table.

Why It Is No Longer Enough

Normalize.css was never designed to handle what modern web development requires:

User preferences. prefers-color-scheme, prefers-reduced-motion, prefers-contrast, forced-colors. None of these existed when normalize.css was written. None of them are handled by its successors either.
Modern CSS properties. text-wrap: balance, field-sizing: content, scrollbar-gutter, @starting-style. These are production-ready today and belong in a base stylesheet.
Keyboard accessibility. :focus-visible replaces the blunt :focus selector. Without it, removing the default outline harms keyboard users.
Form UX. :user-valid and :user-invalid enable validation feedback only after the user has interacted with a field, not on page load.

Normalize.css does none of this. Neither does its most direct successor, modern-normalize.

What It Passed On

Normalize.css also established quality standards worth acknowledging: a readable file, organized into clear sections, with a precise comment above each CSS rule explaining why it is there and what bug or behavior it addresses.

That care for inline documentation is rare in stylesheets. It turns a CSS file into a learning resource: you understand the reasoning, not just the result.

browserux.css was directly inspired by this approach. Every rule is commented, every section is delimited, every choice is justified. The goal is the same: the file should be readable and understandable by anyone who opens it, not just its author.

That is normalize.css's most lasting contribution, and it is worth carrying forward.

What About modern-normalize?

modern-normalize is actively maintained and well-regarded. It inherits normalize.css's philosophy of doing one thing: fixing cross-browser inconsistencies.

It is a good choice if that is all you need. But it deliberately stops there. No user preferences, no modern CSS features, no accessibility improvements beyond what browsers already provide.

If you reach for modern-normalize, you will still end up adding the rest yourself.

A More Complete Alternative: browserux.css

browserux.css starts where normalize.css and modern-normalize stop.

It handles cross-browser normalization, adds a minimal reset where practical (because nobody actually stops at pure normalization), and layers in the modern CSS features and accessibility improvements that a base stylesheet should cover in 2026.

Here is what you get that normalize.css never provided:

System preference support:

@media (prefers-color-scheme: dark) { ... }
@media (prefers-reduced-motion: reduce) { ... }
@media (prefers-contrast: more) { ... }
@media (prefers-reduced-transparency: reduce) { ... }
@media (forced-colors: active) { ... }

Keyboard focus, done right:

:focus {
  outline: none;
}

:focus-visible {
  outline: 3px solid var(--bux-color-focus);
  outline-offset: 3px;
}

Auto-resizing textarea:

textarea {
  field-sizing: content;
}

Layout shift prevention:

html {
  scrollbar-gutter: stable;
}

Balanced headings:

h1, h2, h3, h4, h5, h6 {
  text-wrap: balance;
}

Which One Should You Use?

	normalize.css	modern-normalize	browserux.css
Actively maintained	No	Yes	Yes
Cross-browser normalization	Yes	Yes	Yes
User preference support	No	No	Yes
Modern CSS features	No	No	Yes
Keyboard focus (`:focus-visible`)	No	No	Yes
Form validation UX	No	No	Yes
Native dark mode	No	No	Yes

If you are starting a new project today and writing your CSS manually, browserux.css is the more complete starting point. If you only need cross-browser normalization and nothing else, modern-normalize is the right tool. You can explore what browserux.css adds on the interactive demo.

What you should not use is normalize.css. It served its purpose. It is no longer maintained. The web has moved on.

Try browserux.css

<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/Effeilo/browserux.css/browserux.css">

5 Modern CSS Features Your Reset Sheet Is Probably Missing in 2026

Effeilo — Sat, 04 Apr 2026 14:38:02 +0000

Not just a reset. A browser upgrade.

Most CSS reset sheets were written years ago and have not changed much since. They handle the basics: box-sizing, margins, font inheritance. But CSS has moved fast, and a new generation of properties is now widely supported enough to use in production.

Here are five modern CSS features that belong in your base stylesheet in 2026, and that most reset sheets are still ignoring.

1. `text-wrap: balance`

Unbalanced headings are one of the most common typographic issues on the web. A title breaks onto two lines, with one long line and one word hanging alone underneath. It looks unfinished, and it is entirely avoidable.

h1, h2, h3, h4, h5, h6 {
  text-wrap: balance;
}

text-wrap: balance tells the browser to distribute text as evenly as possible across lines. No JavaScript, no manual <br>, no magic numbers. One line of CSS, applied globally to all headings.

Browser support: Chrome 114+, Firefox 121+, Safari 17.5+.

2. `field-sizing: content`

Textareas have always been a pain point. By default, they are a fixed size and do not grow as the user types. The traditional solution involves a JavaScript resize observer or a hidden mirror element.

textarea {
  field-sizing: content;
}

field-sizing: content makes the textarea grow automatically as content is added, with no script required. It also works on <input> elements, making them expand to fit their content.

As a fallback for unsupported browsers (currently Firefox and Safari), keep resize: vertical so the user can resize manually.

Browser support: Chrome 123+, Edge 123+. Firefox and Safari support is in progress.

3. `scrollbar-gutter: stable`

Layout shifts caused by the scrollbar are a classic problem. When a page transitions from short to tall content, the scrollbar appears and pushes the layout by 15 to 17 pixels. The content jumps. It looks broken.

html {
  scrollbar-gutter: stable;
}

scrollbar-gutter: stable reserves space for the scrollbar permanently, even when it is not visible. The layout never shifts. No padding hacks, no JavaScript measurement, no overflow-y: scroll side effects.

Browser support: Chrome 94+, Firefox 97+, Safari 15.4+.

4. `@starting-style`

Entry animations on the web have always required JavaScript: adding a class after the element is inserted into the DOM, waiting a frame, triggering a transition. It is boilerplate everyone has written a dozen times.

dialog {
  transition: opacity 0.3s ease;
  opacity: 1;

  @starting-style {
    opacity: 0;
  }
}

@starting-style defines the initial state of an element before its first render. The browser transitions from that state to the normal state automatically. No JavaScript, no class toggling, no requestAnimationFrame.

It works particularly well with the native <dialog> element, which now has broad support and is the right way to handle modals in 2026.

Browser support: Chrome 117+, Firefox 129+, Safari 17.5+.

5. `color-scheme: light dark`

Dark mode support is often treated as a feature to build later, with CSS variables, a toggle button, and a localStorage preference. That works, but there is a simpler approach for the base layer.

:root {
  color-scheme: light dark;
}

This single declaration tells the browser to adapt its native elements (scrollbars, form controls, dialogs, the page background) to the user's system preference automatically. No media query, no variable swap, no JavaScript.

For a complete dark mode implementation with CSS variables, you still need prefers-color-scheme. But color-scheme alone already handles everything the browser controls natively.

@media (prefers-color-scheme: dark) {
  :root {
    --bux-color-background: #1a1a1a;
    --bux-color-text: #e8e8e8;
  }
}

Browser support: Chrome 81+, Firefox 96+, Safari 13+.

All Five, Already in Your Base Stylesheet

These five properties are included in browserux.css, a minimal CSS foundation built around modern UX and accessibility. Drop it in before your own styles and you get all of this, plus consistent cross-browser normalization, keyboard focus management, form validation UX, and full system preference support. See it in action on the interactive demo.

<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/Effeilo/browserux.css/browserux.css">

Why I Built browserux.css

Effeilo — Sat, 04 Apr 2026 14:35:00 +0000

Not just a reset. A browser upgrade.

Every web project starts the same way. You add normalize.css or a CSS reset, and move on. Then three hours later, you add a media query for prefers-reduced-motion. Two weeks after that, you copy a scrollbar snippet from Stack Overflow. A month later, you fix focus styles for keyboard users.

By the end of the project, you have accumulated a dozen CSS fragments scattered across files, pulled from different sources, with no structure and no coherence. Then you do it again on the next project.

browserux.css was born from that observation.

It Started with ergonomize.css

Before browserux.css, I built ergonomize.css: a CSS file designed to complement normalize.css with practical UX improvements. It handled things normalize.css deliberately ignored: form ergonomics, media queries for user preferences, mobile tap delays.

It worked, but it was a complement, not a foundation. Over time, I wanted to go further: merge the normalization, the ergonomics, and the accessibility into a single, structured file. That file became browserux.css.

The Problem It Solves

In most web projects, the CSS foundation is assembled on the fly:

A reset or normalize.css to start
A few snippets for better form rendering
Some media queries for user preferences
Focus style fixes for keyboard navigation
Scrollbar tweaks copied from a blog post

These adjustments come from different sources, added at different times, with no global structure. The result: a growing pile of scattered CSS that every new project inherits and rarely cleans up.

There is also an unspoken lie in how normalize.css gets used. In theory, it is enough: it normalizes without resetting, preserves useful styles, and lets the browser do its job. That is a respectable philosophy. In practice, nobody stops there. A global box-sizing: border-box, margin resets on headings, padding removal on lists... these adjustments are nearly universal, but normalize.css does not make them because that is not its purpose.

The real-world result: normalize.css plus a custom reset plus additional snippets. Three stacked layers where one would do. browserux.css starts from that observation and is honest about it: yes, there is some reset in there. Better to do it cleanly, once, in a single structured file.

There is a third problem, more subtle: CSS moves fast. New properties regularly reach enough browser adoption to be used safely in production. field-sizing, text-wrap: balance, @starting-style, scrollbar-gutter... Knowing what to adopt, when, and with which fallbacks, requires constant monitoring that most projects cannot afford.

browserux.css also solves that: staying current with the latest CSS features as browser support matures, without having to do that research yourself. Each version integrates new properties at the point where their support is broad enough to use with confidence.

browserux.css replaces that pile with a single unified file: opinionated where it needs to be, minimal everywhere else.

What It Does

Built around four pillars:

Reset. Removes unwanted browser defaults while preserving behaviors that are useful and semantic. Not a scorched-earth reset that strips everything indiscriminately.

Normalization. Consistent rendering across browsers, without overriding styles that already work well.

Usability. Smooth scrolling, responsive media, auto-resizing textareas, layout shift prevention, mobile tap optimization. Better UX by default, before JavaScript enters the picture.

Accessibility. Native dark mode, reduced motion, high contrast support, forced colors for Windows High Contrast Mode, keyboard-only focus with :focus-visible.

That last pillar is what truly sets browserux.css apart. Five system preferences covered natively, in pure CSS:

@media (prefers-color-scheme: dark) { ... }
@media (prefers-reduced-motion: reduce) { ... }
@media (prefers-contrast: more) { ... }
@media (prefers-reduced-transparency: reduce) { ... }
@media (forced-colors: active) { ... }

No other mainstream CSS foundation covers all five. Zero JavaScript required.

You can see all of these features in action on the interactive demo.

Who It Is For

browserux.css is for developers who write their CSS manually, with or without a preprocessor (Sass, PostCSS), and want a solid foundation without starting from scratch on every project.

If you use Tailwind, Bootstrap, or another CSS framework, their built-in base is likely a better fit for your context. browserux.css is not designed to sit on top of a utility framework.

It is also not a framework itself. It provides no grid, no components, no utility classes. It prepares the ground so everything you build on top of it starts from a clean, accessible, up-to-date baseline.

Try It

<link rel="stylesheet" href="https://cdn.jsdelivr.net/gh/Effeilo/browserux.css/browserux.css">

Forem: Effeilo

Normalize.css Is Dead. Here's What to Use Instead.

What Normalize.css Actually Did

Why It Is No Longer Enough

What It Passed On

What About modern-normalize?

A More Complete Alternative: browserux.css

Which One Should You Use?

Try browserux.css

5 Modern CSS Features Your Reset Sheet Is Probably Missing in 2026

1. text-wrap: balance

2. field-sizing: content

3. scrollbar-gutter: stable

4. @starting-style

5. color-scheme: light dark

All Five, Already in Your Base Stylesheet

Why I Built browserux.css

It Started with ergonomize.css

The Problem It Solves

What It Does

Who It Is For

Try It

1. `text-wrap: balance`

2. `field-sizing: content`

3. `scrollbar-gutter: stable`

4. `@starting-style`

5. `color-scheme: light dark`