Boundary
Know what belongs inside the component.
Platform under construction
Component CSS
Component CSS packages reusable interface behavior, structure and states without leaking random styles across the whole site.
.alert {}
.alert__title {}
.alert--success {}
.alert[data-state="hidden"] { display: none; }
Architecture mental model
A component should own its internal styling, not the whole page.
Component CSS describes a reusable UI piece: a button, card, nav item, alert, modal, form field or lesson tile.
Good component CSS knows its own parts and states. It does not depend on a specific page location unless that dependency is part of the component contract.
The goal is to make a component portable enough to reuse and strict enough to remain visually consistent.
Parts
Name inner elements that need styling hooks.
Variants
Define supported visual versions.
States
Style active, disabled, open, selected and error states intentionally.
Visual model
See the system before adding more selectors.
.alert
The reusable component wrapper.
.alert__title
Internal structure belongs to the component.
.alert--success
Supported visual version.
[data-state]
Runtime condition changes styling.
Good CSS versus fragile CSS
Component with clear states
.alert {}
.alert__title {}
.alert--success {}
.alert[data-state="dismissed"] { display: none; }Page-dependent component
.homepage main div:nth-child(3) .box h2 {
color: green;
}Rules of thumb
Architecture should make the next CSS decision easier.
Define the boundary
Know what the component owns and what the parent layout owns.
Keep selectors close
Component selectors should not depend on deep page structure.
Support real states
Hover is not enough. Think disabled, selected, error, open and loading.
Use variants deliberately
A component should not accept infinite random visual changes.
Avoid layout ownership
The parent layout decides where a component sits. The component decides how it looks internally.
Test with real content
Long titles, missing images and extra buttons reveal weak component CSS.
Production thinking
Scalable CSS is boring, searchable and hard to break.
Why does this matter?
Component CSS is what turns a one-page design into a reusable product interface.
Accessibility
Component states should match accessible state attributes where possible, such as aria-expanded, aria-current or disabled.
Production note
Every reusable component should have a content stress test and a state checklist.
SEO note
Reusable components still need semantic HTML inside. CSS should not force headings, links or buttons into the wrong elements.
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.
- Add an .alert--danger variant.
- Change data-state to hidden and explain what happens.
- Add .alert__action and decide whether it should be a link or button.
Practice assignment
Do this before moving to the next lesson.
- Choose one component and define its boundary.
- Write classes for wrapper, title and text.
- Add one variant and one state rule.
Try it yourself
Build a component with variant and state
Self-check
Before you continue, prove that you understand Component CSS.
Answer these questions before moving on. If you cannot find, name or move a rule safely, the architecture still needs work.
- Can you explain what the component owns?
- Can you keep parent layout out of component CSS?
- Can you support variants without duplicating the whole component?
- Can you map visual states to semantic attributes when relevant?
- Can you test a component with long content?
Senior audit upgrade
A component should not know the page layout.
Component CSS should own inner structure, variants and states. Outer grid placement and page spacing should usually belong outside the component.
Owns
Internal spacing, states, variants and child layout.
Does not own
Page grid columns, outer section margins and one-off page exceptions.
Composable
A component should be usable in more than one layout context.