Equal specificity
Source order matters when selector weight and cascade level are equal.
Platform under construction
Source Order
Source order is the final tie-breaker. If two declarations have the same cascade level and specificity, the one written later wins.
.button--primary { background: #8cffc1; }
.button { background: #101827; }
/* Equal specificity? Later wins. */
Cascade & Control
When everything else ties, later CSS wins.
Source order is simple, but only after you understand what it does not do. It does not beat higher specificity. It does not beat important declarations. It only decides when the competing declarations are otherwise equal.
This is why stylesheet order matters. A component rule loaded after a base rule can override it. A utility class loaded at the end can intentionally win.
Bad source order creates mystery. Good source order creates a readable path from base styles to components to overrides.
Later stylesheet
A stylesheet loaded later can override earlier CSS if the selectors tie.
Component after base
Base styles should usually come before component styles.
Utilities last
Utility classes often live near the end so they can intentionally override.
Visual model
Control CSS by understanding the browser decision path.
The browser does not apply styles emotionally. It follows a priority system. These diagrams make that priority visible before you start changing declarations.
Base
Set general defaults first.
Layout
Add page structure and spacing.
Components
Style reusable UI pieces.
States
Add hover, focus, active and disabled behavior.
Utilities
Small intentional overrides near the end.
Examples
Write CSS that wins for a reason.
Order supports the system
/* 1. Base */
button { font: inherit; }
/* 2. Component */
.button { background: #101827; }
/* 3. Modifier */
.button--primary { background: #8cffc1; }
Order creates surprise
.button--primary { background: #8cffc1; }
.button { background: #101827; }
/* Primary buttons unexpectedly look default again. */
Rules that matter
Control comes from reducing surprise.
CSS becomes easier when every override has a reason. If a rule wins by accident, the next developer has to debug your intention instead of the code.
Know when order applies
Order only breaks ties after earlier cascade checks.
Load base first
General styles should not unexpectedly override components.
Place modifiers after base component rules
Modifiers are meant to adjust the base component.
Avoid random append-only CSS
Throwing fixes at the end of a file creates hidden dependencies.
Group by responsibility
A predictable file structure makes source order easier to reason about.
Use comments or layers for sections
Large files need clear order markers or cascade layers.
Production thinking
The cascade is architecture, not trivia.
Why does this matter?
Source order is simple enough to seem harmless, but messy order creates long-term CSS debt. Good order lets developers predict where a rule should live.
Accessibility
If focus styles are defined early and later button rules override them, keyboard users can lose visible focus. Keep state styles in a reliable position.
Production note
Production CSS should have an intentional loading order. Base, layout, components, states and utilities should not be randomly mixed.
SEO note
Stable source order supports stable rendering. A page that renders predictably is easier to test and maintain.
Live code lab
Change the CSS and watch the interface respond.
The preview runs in an isolated iframe. Links and forms stay inside the practice area, so you can experiment without leaving the lesson.
Mini assignment
Try this now.
- Move .button--primary below .button and run the preview.
- Keep the same selectors and change only their order.
- Explain why the later rule wins only when specificity ties.
Practice assignment
Do this before moving to the next lesson.
- Write base, component and modifier rules in a deliberate order.
- Create a conflict where order decides the winner.
- Refactor the order so the result matches the component intention.
Try it yourself
Move rules and watch source order win
Self-check
Before you continue, prove that you understand Source Order.
Answer these questions before moving on. If the answer is vague, inspect the lab example and trace which declaration wins.
- Can you explain when source order matters?
- Can source order beat a more specific selector?
- Can you organize CSS so modifiers come after base rules?
- Can you spot an override that only works because it is last?
- Can you avoid using the end of the file as a junk drawer?
Senior audit upgrade
File and import order are architecture decisions.
Source order is easy to understand but easy to abuse. A project should load reset, base, layout, components and utilities in an intentional order.
Base first
Put broad foundations before component details.
Components next
Component files should own component styling, not depend on random later overrides.
Utilities last
If utilities are allowed to override components, make that policy explicit.