Page override layer
@layer page sits at the top of the cascade — the safe place for per-page adjustments that should beat components and utilities without a specificity fight.
@layer components
Default card: padding: 1.5rem
@layer page wins
Landing page override: accent border, larger padding
Quick implementation
/* Declare all layers upfront — page is highest priority */
@layer base, components, utilities, page;
/* In a page-specific stylesheet or <style> block: */
@layer page {
/* Override hero padding on the landing page */
.hero {
padding-block: 8rem;
}
/* Landing page uses a wider content column */
.content-wrap {
max-width: 72rem;
}
/* Pricing page highlights its card differently */
.pricing-card {
border-color: oklch(0.52 0.22 265);
box-shadow: 0 0 0 1px oklch(0.52 0.22 265 / 0.3);
}
}Prompt this to your LLM
Includes role, constraints, framework variants, and edge cases.
You are a senior frontend engineer using CSS cascade layers.
Goal: Show how to use @layer page for per-page style overrides in
a multi-page site. The layers in order are:
base, components, utilities, page.
Demonstrate:
- Overriding a .hero component's padding on the landing page only
- Giving a specific page a wider max-width than the global default
- Making a .card on the pricing page render with an accent border
and larger padding, without touching the shared component file
Constraints:
- No !important anywhere — let layer order do the work.
- Show both inline <style> tag usage and a separate page.css file.
- Framework variant: Show how Astro handles per-page scoped styles
alongside a global layer declaration.
Return only the CSS, with brief comments explaining each override.The specificity escape hatch
The page layer means you never need !important for page-specific overrides. Layer order beats specificity — a single-class selector in @layer page wins over a three-class selector in @layer components, every time. This lets you keep shared component files clean and untouched while freely customizing individual pages.
Inline <style> blocks vs external page files
Both work: you can write <style>@layer page { ... }</style> directly in the HTML, or put page-specific overrides in a page.css file that's only loaded on that route. The former is simpler for framework-generated pages (Astro, Next.js, SvelteKit each have their own scoped style mechanism that maps cleanly to the page layer). The latter is better when multiple templates share the same page-level customizations.