LSCSS

Teaching deck

Explain LSCSS in 15 minutes

Good methodology fails when it takes an hour to explain and nobody remembers it on Tuesday. This page is the short version for teams, workshops, onboarding, and architecture buy-in.

Open with the real question

Ask first: Why does CSS feel harder than it should?

Usually not because CSS is difficult.

Usually because ownership is unclear.

Start with delivery pain, not naming theory. People adopt systems when they recognise the problem first.

The real problem

  • Overrides feel unpredictable
  • Developers disagree where CSS should live
  • Utilities quietly become architecture
  • Legacy CSS spreads without clear boundaries
  • Everyone fears one shared stylesheet

This is rarely a CSS syntax problem. It is usually an ownership problem.

The non-negotiables

  • Ownership before selectors
  • Layers before specificity
  • Shallow selectors over deep nesting
  • Utilities are exceptions
  • Hacks are temporary
  • Tokens before random values
  • Calm CSS beats clever CSS

Show common anti-patterns

  • Deep selectors hiding ownership problems
  • Important declarations replacing architecture
  • Modifier names hiding temporary state
  • Magic numbers becoming design decisions
  • Temporary hacks surviving multiple Christmases

People learn fast when they recognise their own code in the evidence.

Adoption without rewrites

A sensible 15 minute teaching flow might cover:

  • The real problem
  • The non-negotiables
  • Decision rules
  • Common anti-patterns
  • Adoption without rewrites
  • What good looks like

Start with layers. Protect new work first. Improve active components. Avoid large rewrite plans without clear delivery value.

Close with this

Good CSS is not impressive because it is clever. It is impressive because nobody is afraid to change it.

The goal is not perfect code. The goal is safer delivery.

Next useful pages