Why Your CSS Reset Fails with @layer

Your CSS reset worked fine until you added @layer to the rest of your stylesheet — now headings have wrong margins, form elements look unstyled, or component base styles bleed through, a symptom that points to one of three fixable causes covered in Normalization & Reset in Layers and the broader Specificity Management & Conflict Resolution discipline.

Prerequisites

This page assumes you understand:

Tooling required: a browser with DevTools (Chrome 99+, Firefox 97+, Safari 15.4+) for layer inspection.

Why Your Reset Breaks: The Three Root Causes

Before stepping through the fix, it helps to know which failure mode you are in. All three trace back to the same underlying rule: unlayered CSS beats all named layers, and layer order is fixed at parse time.

CSS cascade priority in the author origin A vertical stack showing cascade priority from highest (top) to lowest (bottom). From top: Unlayered CSS (highest — always wins), then named layers in reverse declaration order: utilities, components, theme, base, reset (lowest named layer). ▲ higher priority wins Unlayered CSS Beats every named @layer — the most common reason your reset gets overridden @layer utilities — declared last → highest named priority @layer components @layer theme @layer base @layer reset — declared first → lowest named priority ▼ lower priority

Step-by-Step Procedure

Step 1 — Declare the full layer order at the top of your entry stylesheet

What this does: The browser fixes the layer stack the moment it parses the first @layer declaration. Declaring every layer name up front in one statement guarantees that the intended order is locked in before any rule blocks are evaluated, regardless of file order.

/* entry.css — this @layer statement must appear before any @import or rule block */
@layer reset, base, theme, components, utilities;
/* Why: layers are evaluated left-to-right; 'reset' gets the lowest priority,
   'utilities' gets the highest. Without this line, the browser creates layers
   implicitly in the order it first encounters them — which is your file load order,
   not your intended cascade order. */

Step 2 — Import the reset file into the named reset layer

What this does: Wrapping the import in layer(reset) moves the entire reset stylesheet inside that named layer. Without layer(), the imported file remains unlayered and will beat every named layer you declared in step 1.

/* entry.css — @import must come before any @layer rule blocks */
@layer reset, base, theme, components, utilities; /* from step 1 */

@import 'modern-normalize.css' layer(reset);
/* Why: assigning the import to layer(reset) means every rule inside
   modern-normalize.css now carries the lowest named-layer priority.
   Components and utilities can override it without any specificity tricks. */

If you inline the reset rather than importing a file, wrap it in the layer block instead:

@layer reset {
  /* low-specificity type selectors are enough here — layer order, not
     specificity, ensures these are baseline-only and can be overridden */
  *, *::before, *::after { box-sizing: border-box; }
  body { margin: 0; font-family: system-ui, sans-serif; }
  h1, h2, h3, h4, h5, h6 { font-size: inherit; font-weight: inherit; }
}

Step 3 — Wrap every third-party stylesheet in a vendor layer

What this does: Analytics scripts, icon font loaders, and UI library CDN links often inject stylesheets outside any @layer. Wrapping them in @layer vendor brings them into the controlled stack. Consult Resolving Third-Party CSS Conflicts for more strategies around third-party isolation.

@layer reset, vendor, base, theme, components, utilities;
/* Why: 'vendor' is declared after 'reset', so vendor styles override the reset
   where needed (e.g. Bootstrap button reboot), but components and utilities
   can still override vendor. */

@import 'modern-normalize.css' layer(reset);
@import 'https://cdn.example.com/ui-lib.css' layer(vendor);
/* Why: without layer(vendor), ui-lib.css is unlayered and beats everything. */

Step 4 — Reduce specificity inside your reset layer

What this does: Within a single layer, the cascade falls back to normal specificity rules. If your reset uses IDs or class-chained selectors, it can beat component rules that share the same layer — or fail to be overridden by rules in the same layer as intended. Keep reset selectors at element/type level.

@layer reset {
  /* BAD: #app h1.hero-title has specificity (1,1,1) — hard to override
     inside any layer that shares these elements */

  /* GOOD: h1 has specificity (0,0,1) — low enough that any component rule wins */
  h1 { margin-block: 0; line-height: 1.2; }
  button { cursor: pointer; }
  img, svg { display: block; max-width: 100%; }
}

Step 5 — Remove any !important from the reset layer

What this does: The !important flag inverts layer order for important declarations: !important inside an early-declared layer beats !important in a later-declared layer. Using it in @layer reset causes it to win over !important in @layer utilities, which is the opposite of what you want. The role of !important in layers is a common source of confusion — the short version is that you should not use it inside @layer reset at all.

@layer reset {
  /* BAD: !important here will beat !important in utilities — backwards */
  /* body { margin: 0 !important; } */

  /* GOOD: layer order alone is sufficient; no !important needed */
  body { margin: 0; }
}

Verification

After applying the steps above, confirm the fix in DevTools:

  1. Open DevTools → Elements panel, select an element your reset targets (e.g. body, h1, button).
  2. In the Styles tab, look for @layer reset annotations next to your reset rules. The absence of any annotation means the rule is still unlayered.
  3. Check that no unlayered rules appear above your @layer reset block in the Styles panel cascade list. Unlayered rules appear without a layer annotation and will always be listed above named layers in the Styles panel because they have higher priority.
  4. In Chrome 99+ / Firefox 97+, open the Layers panel (or look for the layer toggle in the Styles tab) to see the full layer stack in declaration order.

You can also write a quick console assertion to verify specificity is not leaking:

// Paste in DevTools console to check if any @layer reset rule is being overridden
// by a rule in the same stylesheet that lacks a layer annotation
const sheets = [...document.styleSheets];
sheets.forEach(sheet => {
  try {
    [...sheet.cssRules].forEach(rule => {
      // CSSLayerBlockRule type = 12; log non-layer rules that target body/h1
      if (rule.type !== 12 && rule.selectorText?.match(/^(body|h1|button)$/)) {
        console.warn('Potentially unlayered reset-style rule:', rule.cssText);
      }
    });
  } catch (_) {} // cross-origin sheets throw SecurityError
});

Troubleshooting

Reset rules missing @layer annotation in DevTools : Your reset file was imported without layer(). The browser treated it as unlayered, which appears to work (it wins over named layers) but will silently break when you add a !important rule anywhere in a named layer. Fix: change @import 'reset.css' to @import 'reset.css' layer(reset).

Layer order appears correct but reset is still overridden : A third-party script is injecting a <style> tag at runtime after your layers parse. Runtime-injected styles are unlayered by definition and always win. Fix: intercept the injection with a MutationObserver and move the injected rules into a @layer vendor block, or use @layer vendor at load time for any CDN stylesheet you control.

Reset was working, stopped after adding @layer to a component stylesheet : Before you added @layer components {...}, your reset was implicitly unlayered and won on source order. The moment any stylesheet contains a @layer block, unlayered rules jump above all named layers. Your reset, which was unlayered, was accidentally winning for the wrong reason. The fix is step 2 above: give the reset an explicit layer.

@import statement is silently ignored : Browsers require all @import statements to appear before any rule blocks — including @layer rule blocks. If you have @layer reset { ... } before @import 'normalize.css' layer(reset), the import is discarded. Fix: move all @import lines above all @layer { } blocks (the upfront @layer reset, base, ...; declaration-only statement is fine above @import).

Specificity conflict inside @layer reset itself : If modern-normalize.css uses selectors like [type="button"] (specificity 0,1,0) and you add button { appearance: none; } (specificity 0,0,1) in the same layer, the attribute selector wins within that layer, which may not be what you want. Fix: audit intra-layer specificity or use :where() to zero out specificity on reset rules — button, :where([type="button"]) { appearance: none; }.

Complete Working Example

Copy this into your entry stylesheet and replace the @import paths with your own reset file:

/* ============================================================
   entry.css — layer-aware reset setup
   ============================================================ */

/* 1. Declare the full stack upfront in intended priority order.
      'reset' has the lowest priority; 'utilities' the highest.
      This line alone fixes implicit-ordering bugs. */
@layer reset, vendor, base, theme, components, utilities;

/* 2. Import the reset into @layer reset.
      @import MUST come before any @layer rule blocks below.
      The layer() assignment stops normalize.css from being unlayered. */
@import 'modern-normalize.css' layer(reset);

/* 3. Wrap any third-party or CDN stylesheets.
      Without layer(vendor), these files beat all named layers. */
/* @import 'https://cdn.example.com/ui-lib.css' layer(vendor); */

/* 4. Base tokens and design defaults — above vendor, below components */
@layer base {
  :root {
    --color-text: #1a1a1a;
    --color-bg: #ffffff;
    --font-body: system-ui, sans-serif;
    --spacing-base: 1rem;
  }

  body {
    /* Intentional re-application of font/color as design defaults,
       which override normalize's browser-default preservation */
    font-family: var(--font-body);
    color: var(--color-text);
    background-color: var(--color-bg);
  }
}

/* 5. Component and utility layers follow — each can freely override
      reset and base rules because they are declared later in the stack. */
@layer components {
  .btn {
    /* No specificity tricks needed — layer order guarantees this wins over reset */
    display: inline-flex;
    padding: 0.5em 1em;
    cursor: pointer;
  }
}

@layer utilities {
  /* Single-purpose overrides — declared last so they always win */
  .mt-0 { margin-top: 0; }
  .sr-only {
    position: absolute;
    width: 1px;
    height: 1px;
    overflow: hidden;
    clip: rect(0,0,0,0);
    white-space: nowrap;
  }
}

Frequently Asked Questions

Why do unlayered styles always override my @layer reset?

Unlayered CSS sits above all explicitly declared author layers in cascade priority, regardless of specificity or source order. The spec defines unlayered author styles as implicitly belonging to a final, unnamed layer that is evaluated after all named layers. Assign your reset — and every external stylesheet — to a named @layer to bring it into the controlled stack.

Can I use !important inside @layer reset to force it to win?

No. The !important flag reverses layer order for important declarations: !important inside an earlier-declared layer beats !important in a later-declared layer. Using !important inside @layer reset (the earliest layer) means it will beat !important in @layer utilities (the latest layer) — the exact opposite of your intended cascade. Place your reset in the first-declared layer and use low-specificity selectors; layer order alone guarantees it loses to everything above it, which is the correct behavior for a reset.

My reset worked before I added @layer to other stylesheets — why did it break?

Before you added any @layer blocks, all your stylesheets were unlayered and competed on specificity and source order. The moment any stylesheet gained a @layer block, all still-unlayered CSS — including your reset — gained implicit priority above every named layer. Your reset appeared to work but was winning for the wrong reason (accidental unlayered status). The fix is to assign the reset to @layer reset so it is explicitly in the lowest-priority named layer.