Ordo Antimatter
Back to Notes
5 min read

The best styling is the one you can remove later

Maintainable design systems prioritize deletion over addition. CSS should be as disposable as the features it styles.

CSSMaintenanceArchitecture

The Best Styling Is the One You Can Remove Later


Maintainable design systems prioritize deletion over addition. CSS should be as disposable as the features it styles.


The Accumulation Problem


CSS has a unique property: it's easier to add than to remove. Over time, stylesheets become archaeological sites:


  • Styles for components that no longer exist
  • Overrides stacked upon overrides
  • Magic numbers that nobody remembers
  • Selectors that are too specific to change safely

    • Designing for Deletion


    The best CSS is written with its eventual removal in mind:


    1. Scope Everything

    Instead of global styles, use scoped selectors that are easy to identify and remove.


    2. Avoid Deep Nesting

    Shallow, specific selectors are easier to override and remove than deeply nested ones.


    3. Use Utility Classes Sparingly

    Component-based styles with utilities for spacing work better than utility-heavy markup.


    The Component Lifecycle


    Every CSS rule should have a clear lifecycle:


  • **Birth**: Written for a specific component or feature

    • 2. Growth: Extended and refined as needed

    3. Maturity: Stable and well-understood

    4. Death: Removed when the component is deprecated


    Strategies for Removable CSS


    1. Co-location

    Keep styles close to the components they style.


    2. Explicit Dependencies

    Make it clear what styles depend on what.


    3. Automated Cleanup

    Use tools to find unused styles:

  • PurgeCSS for removing unused classes
  • CSS coverage in DevTools
  • Linters that flag unused selectors

    • 4. Documentation

    Document the purpose and dependencies of your styles.


    The Refactoring Test


    Good CSS passes the refactoring test:

  • Can you rename a component without breaking styles?
  • Can you remove a feature without leaving orphaned CSS?
  • Can you change the design without archaeological CSS digging?

    • Framework Considerations


    Different approaches to removable CSS:


    CSS Modules

  • Scoped by default
  • Clear file boundaries
  • Easy to remove with component

    • CSS-in-JS

  • Truly scoped to components
  • Dies with the component
  • Can be over-engineered

    • Utility-First (Tailwind)

  • Highly removable individual classes
  • But can create coupling in templates
  • Good for rapid prototyping

    • Traditional CSS

  • Requires discipline
  • Easy to accumulate cruft
  • But simple and widely understood

    • Practical Guidelines


  • **One feature, one CSS file** - when the feature goes, the CSS goes

    • 2. Avoid !important - it makes removal risky

    3. Use CSS custom properties - easier to change values later

    4. Keep specificity low - easier to override and remove

    5. Regular CSS audits - schedule time to remove unused styles


    The Business Case


    Removable CSS saves money:

  • **Faster development** - less time fighting existing styles
  • **Smaller bundles** - better performance for users
  • **Easier onboarding** - new developers aren't afraid to change things
  • **Reduced bugs** - fewer style conflicts and edge cases

    • Conclusion


    The best CSS is not the cleverest CSS—it's the CSS that doesn't get in your way when you need to change or remove it.


    Write CSS like you're writing code that someone else will need to delete. Because they will.