CSS Specificity Notation: A Push for Clearer (X, X, X, X) Syntax

A recent reflection on CSS specificity highlights a long-standing communication problem: how we write about specificity can actively mislead developers. The issue stems from portraying specificity as a base-10 number system, a framing that breaks down under real-world selectors.

The Problem with Base-10 Thinking

Consider a selector like ul.nav. In a base-10 model, you’d call its specificity 0011 (eleven). That implies numeric values: tags = 0, classes = 10, IDs = 100, and a style attribute = 1000. But that logic collapses quickly. A selector with ul.nav plus ten more class names would yield a specificity of 0111 by that arithmetic. That would incorrectly tie it with ul#nav.top. In reality, the former is (0, 0, 11, 1) while the latter is (0, 1, 0, 1) — and the ID-based selector wins outright.

Why Commas Work Better

The comma-separated tuple notation fixes two core issues:

  1. It avoids implying any base-10 (or other numeral) system.
  2. It offers a distinct, readable visual format.

The (X, X, X, X) structure is appealing. Some might trim it to three slots since a style attribute isn’t truly a selector, nor is it usually discussed in the same context. The parentheses add clarity, though a dash-separated X-X-X variant could drop them, while a slash-delimited (X / X / X) would likely still benefit from them.

Spec history is mixed on this. Selectors Level 3 briefly uses dashes, while Level 2 used both dashes and commas in different spots. The ongoing ups and downs suggest the notation debate isn’t settled — but a clear, familiar tuple syntax might finally settle it for good.