Framework override layer
Override framework styles without !important — just declare your layer last.
Same selector weight — the overrides layer wins because it's declared last in @layer.
Quick implementation
/* Declare order: framework first, your overrides last */
@layer framework, overrides;
/* Wrap the third-party framework in its layer */
@layer framework {
.btn {
padding: 0.5rem 1rem;
border-radius: 0.25rem;
background: oklch(0.32 0.03 260);
color: oklch(0.75 0.02 260);
font-weight: 400;
border: none;
cursor: pointer;
}
}
/* Your overrides — wins automatically, no !important needed */
@layer overrides {
.btn {
border-radius: 0.5rem;
background: oklch(0.52 0.22 265);
color: oklch(0.98 0.005 260);
font-weight: 600;
}
}
Prompt this to your LLM
Includes role, constraints, two framework variants, and edge cases to handle.
You are a senior frontend engineer integrating a UI framework into a design system.
Goal: Override third-party framework styles using CSS @layer — no !important.
Technical constraints:
- Declare @layer framework, overrides; at the top so the order is explicit.
- Wrap all framework imports or styles in @layer framework { ... }.
- Place all custom overrides in @layer overrides { ... } — it wins because it's last.
- Use oklch() for all colors, not hex or rgba().
- Selector specificity does not matter between layers — only layer order matters.
Framework variant (pick one):
A) Vanilla CSS — inline @layer blocks in a single stylesheet.
B) Sass/PostCSS — @layer framework { @import 'bootstrap'; } at the top, overrides in a separate file.
Edge cases to handle:
- Framework styles loaded via <link> are unlayered by default and will beat your @layer overrides — fix with @import inside a @layer block.
- If you cannot change how the framework loads, wrap its styles retroactively using a @layer with a lower priority in the declaration order.
- Confirm that !important inside a lower-priority layer still loses to a non-important rule in a higher-priority layer.
Return CSS only.
Why this matters in 2026
Every team that uses a CSS framework eventually fights it. Overriding Bootstrap, Tailwind base styles, or any third-party component library without !important used to require selector gymnastics — adding extra classes, using IDs, or nesting rules deeper. @layer eliminates all of that. Wrap the framework in a low-priority layer, put your styles in a higher one, and the cascade does the rest.
The logic
The declaration @layer framework, overrides; is the entire trick. It tells the browser: anything in framework loses to anything in overrides, regardless of selector specificity. A single .btn class rule in overrides will beat a .theme .container .btn rule in framework. The layer order is the only thing that counts between layers.
The critical gotcha: CSS loaded via a plain <link> tag is unlayered, which means it implicitly beats all @layer rules. To solve this, load the framework via @import inside a @layer framework { @import url("framework.css"); } block — this places it in the layer.
Accessibility & performance
There is no runtime cost — layer resolution happens at CSS parse time. The only risk is the unlayered-styles gotcha described above. A helpful rule of thumb: if you control all your CSS, wrap everything in layers from day one. If you are adopting layers incrementally into an existing codebase, treat any unlayered styles as the highest-priority implicit layer and migrate them into named layers gradually.