CSS Classes Considered Harmful

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.