Selectors & Specificity

The class attribute is not a single name but a space-separated list of class names. An element can carry as many classes as needed, as in <div class="tarjeta destacado activo">, and each class can be targeted on its own: .tarjeta, .destacado and .activo each match that div independently. As a consequence, the element receives the declarations of every rule whose selector matches it, so styles from all three classes are combined on the same element.

Class selectors can also be chained without whitespace to require several classes on the same element:

The order in which the classes are written in the selector, and in the class attribute, is irrelevant, and extra classes on the element never prevent a match. Given the following elements:

When two matching rules set the same property with the same specificity, the rule that appears later in the stylesheet wins. The position of a class within the class attribute plays no part: writing class="activo tarjeta" instead of class="tarjeta activo" changes nothing.

A common way to use several classes is the base-and-modifier pattern, for example <div class="card card--featured is-active">: card holds the shared styling, card--featured is a variant and is-active is a state. The card--featured naming comes from BEM, covered in Suffixing the parent selector for BEM. From JavaScript, prefer element.classList.add(), remove(), toggle() and contains() to change a single class, because assigning element.className replaces the whole list and discards the other classes.

The most common introduction to pseudo-classes is styling the four states of an anchor element:

The order these rules are written in matters, because later rules of equal specificity override earlier ones in the cascade. Writing a:hover before a:link, for example, would cause the :link rule to win and the hover effect would never be visible. The mnemonic for the correct order is LoVe HAte: Lo(:link), V(:visited), H(:hover), A(:active).

Beyond link states, some of the most useful pseudo-classes are:

:nth-child() accepts either a keyword (odd, even) or a functional notation such as 3n - 1, giving a lot of flexibility for styling repeating patterns:

Applied to a plain <ul> of seven <li> items, this colors every third item (starting from the 2nd) skyblue, and every third item after that (the 3rd, 6th, …​) deepskyblue, leaving the rest unstyled.

Two class selectors can be joined in four different ways that look similar but select very different elements. All of them are compared here against the same markup, whose elements are numbered:

The distinction between + and ~ is easiest to see against a single list where one item carries a .selected class:

With +, only Item 5 matches — it is the single element immediately following .selected. With ~, every later sibling (5, 6, and 7) matches, because ~ matches any following sibling, not just the adjacent one. Combining a sibling combinator with a structural pseudo-class narrows this further — for example, li.selected ~ li:nth-child(odd) selects only the odd-numbered items after the selected one.

Comparing the two, (0, 2, 1, 1) beats (0, 0, 2, 2) because the comparison works left to right: as soon as one selector has a higher count at a given position, it wins outright, regardless of what follows. Two IDs in the second selector settle the comparison before the class/element counts are even considered.

The !important keyword can be appended to any CSS declaration’s value. It effectively sets that declaration’s specificity to (1, 0, 0, 0, 0) — a rank above even inline styles — so it takes precedence over any other rule for that property, regardless of selector specificity.

Given <div class="media hide">, it might look like .hide should win because it is declared second. But by the specificity rules above, div.media scores (0, 0, 1, 1) while .hide scores only (0, 0, 1, 0) — so the display: block of div.media overrides the display: none of .hide, and the element is not hidden. Writing class="hide media" instead makes no difference, because the order of the classes in the attribute has no effect, and moving .hide later in the stylesheet helps only when both selectors have equal specificity. Adding !important fixes this:

This makes .hide reliably win regardless of what else targets the same element, which is exactly why !important is reserved for small, single-purpose utility classes like this one — overusing it forces every future override to reach for !important as well, defeating the purpose of specificity in the first place.

Nesting lets you group related selectors the way Sass has long allowed, instead of repeating a shared prefix on every line:

A child selector can also be written explicitly with the & nesting selector, which stands for "the parent selector" and is required when the nested selector doesn’t start with a combinator, a class, or an ID (for example, when combining with a pseudo-class):

The & also controls how a nested class combines with its parent. Inside .tarjeta { }, &.activo compiles to .tarjeta.activo (the same element carries both classes), whereas & .activo and a bare .activo both compile to .tarjeta .activo (an .activo descendant):

Nesting also supports at-rules such as media and container queries directly inside a rule, instead of wrapping the whole rule in a separate block:

Because the nested styles live alongside the component they belong to, removing a component’s markup lets you delete its entire style block in one place, instead of hunting for related selectors scattered elsewhere in the stylesheet.

:has() is a functional pseudo-class that selects an element if any of the relative selectors passed to it match at least one element within (or, via a leading combinator, relative to) it — effectively a "parent selector" or "previous sibling selector", which CSS previously had no way to express.

Given

only the second .card gets the border and background, because only it contains a .highlight descendant. :has() cannot be nested inside another :has(), and pseudo-elements cannot appear as selectors within it or serve as its anchor.

@layer addresses the specificity problem from a different angle: instead of relying on selector specificity alone, you explicitly declare named layers, and layer order takes priority over selector specificity when resolving conflicts between layers.

Even though .nav-link has higher selector-level specificity than the bare a selector, the theme layer’s a { color: purple } still wins over the base layer’s .nav-link { color: blue }, because layer order is consulted before specificity. Layer precedence is determined by the order in which layer names are first declared — you can reverse it explicitly:

With this ordering, the base layer now takes precedence over theme, so links revert to black (and .nav-link ones to blue) — adjusting layer order is therefore a way to manage which whole groups of styles take precedence, without touching individual selectors.

@scope limits where a set of CSS rules applies, encapsulating a rule so it only affects a specific subtree instead of the whole document — addressing the same problem naming conventions (like BEM) and CSS-in-JS libraries have traditionally solved without native browser support.

Here, .title only matches inside a .card, so it can’t clash with unrelated .title elements elsewhere on the page. The full syntax also accepts a lower bound:

<scope-start> is the scoping root (the upper bound); the optional to (<scope-end>) narrows the scope further by excluding everything from the named lower-bound selector downward:

img only matches images within a .media-object, and .content is styled, but styling stops at the .content > * boundary — the direct children of .content are excluded from the scope, so nested components inside .content are free to define their own, unrelated styles without being caught by this rule.