CSS Classes Considered Harmful

Original Article ↗ Hacker News Discussion ↗

Proposed Alternative: Custom Elements + Data Attributes

  • Core idea praised by some: represent components as custom tags (e.g., <my-card>) and use attributes (e.g., data-size="big") instead of multiple classes.
  • Benefits cited:
    • Avoids class “soup” and name collisions.
    • Encodes mutually-exclusive state via single attributes (size=big/medium/small) instead of many overlapping classes.
    • Keeps visual details in CSS while state/variants live in HTML attributes.
  • Some like using one “semantic” class plus attributes (class="my-thing" data-level="3"), rather than many BEM-style modifier classes.

Skepticism About Replacing Classes

  • Many see data-attributes as “classes with extra steps” and not a real improvement.
  • Concern that this just moves namespacing and combinatorics from classes to attributes and custom tags.
  • Some argue .Card.big (or BEM-style modifiers) already solves most problems cleanly, especially with preprocessors.
  • Critics worry about mixing state and style in attributes, making HTML less restylable and more tightly coupled to presentation.

Semantics, Content vs Presentation

  • Recurrent theme: “name things for what they are, not how they look,” but several say this is hard to enforce in real projects.
  • Others counter that size/layout is inherently presentational and often context-driven (.hero .card vs .articles .card).
  • Some argue strict separation of content and style is more theoretical than practical; modern layout (flex/grid) tightly couples HTML structure and CSS.

Utility / Atomic CSS vs Alternatives

  • Defenders of functional/atomic CSS (including Tailwind-like systems) say they reduce mental load and avoid OOCSS bloat, though syntax can be hard to learn.
  • Others dislike Tailwind as unreadable “inline styles in class attributes,” but acknowledge why teams adopt it.
  • Several commenters prefer simple class-based systems (BEM, ECSS, SCSS placeholders) plus linting over new attribute-driven schemes.

HTML as Document vs Application Platform

  • Debate over whether HTML/CSS are well-suited to full applications:
    • Some say apps don’t map well to HTML; many UI primitives (dialogs, popovers, complex selects, drag-and-drop) arrived late or require heavy JS.
    • Others argue the web’s ubiquity and deployment simplicity outweigh these mismatches, so the platform is being bent into an app runtime.

Tooling, Performance, and DX

  • Note that browsers optimize ID/class selectors; attribute selectors can be slower for JS queries.
  • Editor tooling today is heavily optimized around class strings; attributes/custom tags might enable richer tooling but are less supported now.
  • Some highlight new CSS capabilities (:has(), grid/flex, attr() in future specs) as underused ways to manage complexity without abandoning classes.

Accessibility, SEO, and Custom Elements

  • Concern that replacing semantic tags with custom elements harms accessibility and requires extra ARIA work.
  • Clarification that if no semantic element exists, a custom tag is no worse than a <div>, but it still shifts responsibility to developers.
  • One person worries about SEO impact of custom tags; others note standards aim to keep custom element/attribute naming safe (e.g., requiring dashes).

Meta: Human Factors and CSS Complexity

  • Several note that most teams lack deep CSS expertise; methodology problems are often social/organizational, not purely technical.
  • Some see the entire debate as bikeshedding; CSS is “simple enough” if used as intended, and overengineering is the real issue.
  • Others view the proliferation of rules, methodologies, and tooling as evidence that CSS’s design doesn’t align well with how people build modern UIs.