What is the difference between the CSS selectors :before and ::before, and which pseudo-elements refuse the single-colon form?

## Two families, one punctuation mark CSS has two kinds of selector that attach to an element with a colon: - **Pseudo-classes** match an element in a particular *state* or structural position: `:hover`, `:checked`, `:first-child`. - **Pseudo-elements** address a *rendered sub-part* of an element that has no element of its own: the generated boxes, the first line, the list marker, the placeholder text. CSS2 spelled both with a single colon, so `:hover` and `:before` looked identical in shape despite doing categorically different things. Selectors Level 3 fixed the ambiguity by giving pseudo-elements a double colon: `::before`. ## Why the old spelling still works The change was cosmetic, and by the time it landed the single-colon spelling was baked into a large amount of deployed CSS. Browsers therefore continue to accept the legacy form for exactly the four pseudo-elements that CSS2 defined: ```css p:first-letter { font-size: 2em; } /* legacy, still matches */ p::first-letter { font-size: 2em; } /* modern, identical result */ ``` The pairs are interchangeable: `:before`/`::before`, `:after`/`::after`, `:first-line`/`::first-line`, `:first-letter`/`::first-letter`. Historically the single-colon form mattered because Internet Explorer 8 understood only that spelling, which is the reason so much older CSS uses it. That constraint is long gone. ## Everything newer is double-colon only Pseudo-elements specified after Selectors 3 have no legacy alias at all: ```css ::marker { color: crimson; } ::selection { background: yellow; } ::placeholder { color: #888; } ::backdrop { background: rgb(0 0 0 / 0.6); } ::file-selector-button { border-radius: 0; } ``` Writing `:marker` or `:placeholder` produces a selector the browser does not recognise. It does not fall back — it simply never matches. ## The invalidation trap A plain selector list is **not forgiving**: if any selector in a comma-separated list is unparseable, the entire rule is discarded. This bit teams badly during the placeholder-prefix era, when people wrote lists mixing standard and vendor-specific spellings: ```css /* the unrecognised entry kills the whole rule */ ::placeholder, :-some-nonstandard-placeholder { color: #888; } ``` The fix is to write each spelling as its own rule so one bad selector cannot take the good one down with it: ```css ::placeholder { color: #888; } ``` This is a general property of selector lists, not something specific to pseudo-elements — but pseudo-elements are where people most often mix spellings, so it is where the trap springs. ## Structural rules worth knowing A few syntactic constraints follow the pseudo-element family regardless of colon count: - A pseudo-element goes at the **end** of a compound selector. `.a::before .b` selects nothing useful, and `::before:hover` is legitimate only in the sense that pseudo-*classes* may follow a pseudo-element in modern syntax; a second pseudo-element may not. - Only one pseudo-element per selector, with the narrow exception of a pseudo-element on top of another where the spec explicitly allows it. - Pseudo-elements are not allowed inside `:has()` as the subject, and support for them in some functional selectors is limited — when unsure, write the plain form and test. ## What to write today Use two colons everywhere. It is unambiguous, it is what every current specification uses, it matches what linters and formatters expect, and it means a reader never has to ask whether `:first-line` was meant as a state. If you are reading an old codebase, the single-colon spellings are not bugs and do not need a migration for correctness — but converting them removes a class of confusion for free.