Components, Naming, and Organization

What this is. A stylesheet that works is not the same as a stylesheet you can maintain. The difference is almost entirely about naming and where things live.

A component is a self-contained piece of interface: a card, a button, a nav bar. Its styles should be grouped together and named after what it is, so you can find them without searching.

Two ways to name the same thing

BY ROLE

.card { }
.card__title { }
.card__meta { }
.card--featured { }

/* the block, its parts,
   and a variant */

BY APPEARANCE

.big-red-box { }
.bold18 { }
.mt20 { }
.thing2 { }

/* describes appearance,
   so it lies the moment
   the design changes */

Compare → The left names survive a redesign. A class called .big-red-box that is now small and blue is actively misleading, and everyone becomes afraid to touch it. Name what a thing IS, never what it currently looks like.

A dependable order for a stylesheet. Custom properties and resets first, then base element styles, then layout, then components, then utilities, then media queries. Following the same order every time means you always know roughly where to look, and it works with the cascade rather than against it.

✦ Specificity should stay flat

If your selectors look like .page .content .card .title span, any future override needs to be even more specific, and the ratchet only turns one way. Aim to style components with a single class wherever you can. Flat specificity is what keeps a stylesheet editable.

LIVE PREVIEW

loading editor…

Your turn → Add a third card and give it the featured modifier. You wrote no new CSS, because the component already describes both of its states.

Mark this lesson complete

Signed in, your progress follows you to every device.

Next: DevTools, Debugging, and Going Live →

← Back