在HTML和CSS中，为何选择类而非自定义属性进行样式设置？

Great question! I totally get where you're coming from—using custom attributes for styling does feel intuitive, especially since toggling them with vanilla JS is straightforward (no messing with classList methods). Let's break down why classes remain the standard choice for most developers, even in vanilla environments:

1. Semantics & Standardization #

The class attribute is explicitly designed in HTML for grouping elements by style or behavior. It carries clear semantic meaning: other developers seeing class="button-primary" immediately recognize it as a styling-related class. Custom attributes like [button-type="primary"], on the other hand, can be ambiguous—are they for styling, storing data, or something else? This ambiguity makes collaboration harder, especially on larger teams.

2. CSS Selector Performance #

While performance differences might be negligible for small apps, class selectors are heavily optimized by browser rendering engines. Browsers use hash tables to quickly look up elements by class, whereas attribute selectors (especially those with value matches like [my-attr="value"]) require traversing elements and checking attribute values one by one. In large DOM trees, this can add up to noticeable differences in style calculation time.

3. Tooling & Ecosystem Support #

Virtually all CSS tooling is built around classes:

• Preprocessors like Sass/Less have built-in features for class-based organization (e.g., nested classes).
• Editor plugins auto-complete class names, highlight unused classes, and sync with your CSS files.
• Linting tools (like Stylelint) can detect issues with class naming conventions.
  Custom attributes get far less support from these tools, making development slower and error-prone.

4. Avoiding Future Conflicts #

Custom attributes run the risk of clashing with future HTML standard attributes. For example, if you use [theme] for styling, and a future HTML spec introduces a native theme attribute, your code could break unexpectedly. Class names, by contrast, are easy to namespace (e.g., myapp-button-primary) to avoid conflicts with native features or third-party code.

5. Flexible Style Combinations #

Classes excel at combining multiple styles. You can easily stack classes like class="button primary large" to apply multiple sets of styles. With custom attributes, you'd either need to use multiple attributes (cluttering your HTML) or store multiple values in one attribute (e.g., [button-props="primary large"]), which requires parsing strings to modify individual values—far less convenient than using classList.add()/remove().

6. Accessibility & Broad Compatibility #

While modern browsers support attribute selectors, older assistive technologies may not interpret custom attributes as reliably as classes. Additionally, class selectors work in every browser ever made (including IE6), whereas attribute selectors have limited support in IE8 and below. If you need to support legacy environments, classes are the safer choice.

When Custom Attributes Are Great #

Don't discount your approach entirely! Custom attributes shine when you need to tie styling directly to dynamic data. For example:

[data-user-role="admin"] {
  background-color: #ffeb3b;
}

Toggling this with element.setAttribute('data-user-role', 'admin') is clean and direct. They're also useful for one-off, data-driven styling cases where classes would feel redundant.

At the end of the day, much of the preference for classes comes from convention and ecosystem support—but there's no one-size-fits-all answer. If your attribute-based workflow works for you and your team, keep using it!

内容的提问来源于stack exchange，提问作者Bradass