CSS Systems for Reusable Sections

Build a small CSS system with spacing, naming, and shared section patterns before you refactor components.

Why CSS Systems Matter

In a small project, it is easy to get away with section-specific CSS. You style the hero, then the gallery, then the footer, each as if it is a separate problem. The trouble appears later when you add another page or try to refactor repeated markup.

A small CSS system helps you answer questions like these more consistently:

• How wide should most content sit on the page?
• How much vertical spacing should sections share?
• What does a standard card shell look like?
• How should buttons and links feel related?
• Which rules belong everywhere, and which belong only in one section?

Start with Shared Tokens

In BSB Part 2, you already used custom properties for colour. That is the right starting point. Now expand that thinking a little. If the same spacing and width values appear again and again, they should be named once and reused.

:root {
  --color-page-bg: #f8f5f0;
  --color-surface: #ffffff;
  --color-text: #2d2a26;
  --color-accent: #8c5e3c;

  --space-xs: 0.5rem;
  --space-sm: 1rem;
  --space-md: 1.5rem;
  --space-lg: 3rem;
  --space-xl: 5rem;

  --content-width: 72rem;
  --card-radius: 0.75rem;
  --border-soft: 1px solid #e5ddd3;
}

These values do not need to be perfect. They need to be intentional. The real benefit is that you stop making up new numbers for every section.

Why this helps

• Changing one value can improve consistency across the whole page.
• Spacing decisions become easier to explain and reuse.
• Later responsive adjustments are easier because you already know your core values.

Name by Purpose, Not Appearance

Naming is where many beginners either become too vague or too specific. A class like .brown-box may feel descriptive today, but it becomes awkward once the colour changes. A class like .left-section-large also ties the rule to a specific layout position that may not stay true.

Better names describe the job the class performs:

• .container for a shared content width
• .section for shared vertical rhythm
• .section-title for headings that repeat the same pattern
• .card for repeated content shells
• .button or .button-primary for action styles

Build Section Patterns First

The most useful shared CSS often starts at section level. Before worrying about every small element, make sure your sections share a calm, readable structure.

.container {
  width: min(100% - 2rem, var(--content-width));
  margin-inline: auto;
}

.section {
  padding-block: var(--space-xl);
}

.section-title {
  margin-bottom: var(--space-md);
  font-size: 2rem;
  line-height: 1.2;
}

.section-intro {
  max-width: 42rem;
  margin-bottom: var(--space-lg);
}

These classes are not flashy, but they do a lot of heavy lifting. Once they exist, most new sections start from a familiar base instead of a blank slate.

Section-level questions to ask

• Does this section need the standard vertical rhythm, or is it a special case?
• Does the content need the shared page width, or a deliberately narrower measure?
• Can this heading reuse the same visual pattern as earlier section titles?

Standardise Repeated Pieces

Once your section shells are stable, look at the repeated pieces inside them. In BSB, that includes cards, calls to action, navigation links, and buttons.

Start with the shell before the variation:

.card {
  padding: var(--space-md);
  background: var(--color-surface);
  border: var(--border-soft);
  border-radius: var(--card-radius);
}

.card-grid {
  display: grid;
  gap: var(--space-md);
}

.button-primary {
  display: inline-block;
  padding: 0.75rem 1.25rem;
  background: var(--color-accent);
  color: white;
  text-decoration: none;
  border-radius: 999px;
}

Notice the order of thinking here: first, define what the shared pattern is. After that, handle section-specific differences only where they are genuinely needed.

Organise Styles Without Overengineering

At this stage, you do not need a complex architecture or multiple build steps. You do need some discipline. Keep your CSS organised in a way another learner could read.

A simple order often works well:

1. Root variables and document-wide basics
2. Layout foundations such as container and section
3. Repeated patterns such as cards, buttons, and link groups
4. Section-specific adjustments only when shared rules are not enough

/* 1. Shared tokens */
:root { ... }

/* 2. Page-wide foundations */
body { ... }
.container { ... }
.section { ... }

/* 3. Reusable patterns */
.section-title { ... }
.card { ... }
.button-primary { ... }

/* 4. Section-specific adjustments */
.hero { ... }
.gallery { ... }
.footer { ... }

This keeps your system readable without pretending the project is bigger than it is.

Accessibility Checks for Shared Styles

Shared styles should help accessibility, not quietly damage it. As your CSS system grows, check a few practical things:

• Do buttons and links keep enough colour contrast?
• Are spacing choices improving readability, not crowding content?
• Do focus states remain visible when a link or button is tabbed to?
• Are decorative choices making content harder to scan?

You do not need a full accessibility deep dive in this lesson, but you do need the habit of checking whether your “shared pattern” is shared responsibly.

Guided Practice

Independent Practice

Additional Resources

These are especially helpful if you want to strengthen your CSS system thinking:

• Every Layout — useful for thinking about stack, cluster, sidebar, and grid patterns as reusable building blocks.
• BEM — Block Element Modifier — useful when your naming needs to become more deliberate as the site grows.

Recap

A strong intermediate CSS habit is learning to see repeated decisions early. Shared tokens, purposeful names, section shells, and repeated card or button patterns all make the next page easier to build. That is the real value of a CSS system.