CSS Specificity Visualizer — Free HTML CSS JS Snippet

CSS specificity is usually taught as a memorization trick — "IDs beat classes, classes beat elements" — without ever showing the actual tuple comparison that determines which rule wins when two selectors target the same element. This snippet computes real specificity tuples from selectors you type or pick, animates each tier counting up one at a time, and then applies the genuinely winning selector's style to a demo element by running the same three-way tuple comparison browsers themselves use — including the two well-known exceptions that outrank specificity entirely: inline styles and !important.

Parsing specificity with regex tiers, not a full CSS parser

specificityOf(sel) counts three tiers directly from the selector string using targeted regular expressions, mirroring the W3C's own three-part specificity model: ids counts #id matches, classes counts class selectors (.class), attribute selectors ([attr]), and pseudo-classes (:hover, :nth-child()) together since the spec weights all three identically, and elements counts bare type selectors (div, span) and pseudo-elements. This is not a full CSS parser — it is a purpose-built counter that strips each matched pattern out of the string as it counts it (so .card.featured correctly yields two class matches instead of one), then counts whatever bare identifiers remain as element selectors. This mirrors how you'd manually count specificity by eye, just automated and instant.

Why classes, attributes, and pseudo-classes share one tier

A common point of confusion is that [data-active="true"], .card, and :hover all look like different kinds of selectors but contribute identically to specificity — the CSS spec deliberately groups them into a single middle tier, distinct from IDs (highest) and elements/pseudo-elements (lowest). The preset chips deliberately include one of each (.card, [data-active="true"], .card:hover) so comparing their resulting tuples side by side makes this grouping visible rather than assumed.

Animating the tuple count-up, tier by tier

compare() builds one badge row per selector, each containing three .tier spans (ID, class, element) that start scaled down and transparent. The function then awaits a short delay before adding the .shown class to each tier in sequence — ID tier first, then class, then element — producing a visible "counting in" animation using a spring-like cubic-bezier(0.34,1.56,0.64,1) easing curve that gives each badge a small bounce as it appears. This tier-by-tier reveal is deliberate: it mirrors the actual order specificity comparison happens in (ID tier is compared first and can short-circuit the whole comparison before class or element tiers are ever consulted), so watching badges fill in that exact order builds the correct mental model of the comparison algorithm, not just the final numbers.

Correct three-tier tuple comparison, not total-score addition

A common misconception is that specificity is a single summed number — that ten classes could outweigh one ID. resolveWinner() deliberately never sums the tiers together; it compares ids first and only moves to comparing classes if the two selectors' ID counts are exactly equal, then only compares elements if both ID and class counts tie. This lexicographic tuple comparison is exactly how the CSS specification defines specificity resolution, and it is why a selector with one ID ((1,0,0)) always beats a selector with fifty classes ((0,50,0)) — a fact that a naive "add up the numbers" implementation would get wrong.

The two real exceptions: !important and inline styles

The !important checkbox does not add weight to a tuple at all — it is implemented as a completely separate override path in resolveWinner(), checked before the tuple comparison even runs: if a selector has !important applied, it wins outright regardless of what its own or any other selector's specificity tuple says, exactly matching real CSS cascade behavior where !important promotes a declaration to a separate, higher-priority origin layer rather than adjusting its specificity score. The winner readout explicitly calls this out with its own sentence ("winning purely because of !important...") whenever it is the deciding factor, so the override is never confused with a naturally high specificity value.