In CSS, what happens to a rule when one selector inside :is() is unknown to the browser, and how does that differ from a plain comma-separated selector list?

## The default rule: one bad selector kills the rule CSS parsers are built to skip what they do not understand, but the granularity matters. For a selector list, the unit is the **whole rule**. If any selector in a comma-separated list fails to parse, the entire rule — every selector in the list and every declaration in the block — is thrown away: ```css /* If the engine does not understand the second selector, .intro loses its colour too. */ .intro, :some-unknown-thing { color: rebeccapurple; } ``` This is why grouping a vendor-specific selector with a standard one has always been a bug. The classic historical example is placeholder styling, where authors grouped several engine-specific selectors into one list and every browser dropped the rule because it recognised only its own. ## Forgiving selector lists `:is()` and `:where()` are defined to take a **forgiving selector list**. Parsing works per argument: anything the engine cannot handle is discarded, the rest is kept, and the rule survives. ```css p:is(.intro, :some-unknown-thing) { color: rebeccapurple; } /* Behaves as p:is(.intro) in an engine that does not know the second argument. */ ``` A useful consequence: you can pair a standardised selector with an engine-prefixed one that means the same thing and let each browser take whichever it recognises: ```css input:is(:autofill, :-webkit-autofill) { box-shadow: 0 0 0 100px canvas inset; } ``` Both of those are real pseudo-classes — `:autofill` is the standard one and `:-webkit-autofill` the older WebKit form — and the forgiving list means neither one's absence breaks the other. ## The exceptions: :not() and :has() The forgiving behaviour is a property of the specific function, not of functional pseudo-classes in general. `:not()` is **not** forgiving. `p:not(.a, :unknown)` is invalid as a whole. That is semantically necessary: dropping an argument from a negation would silently *widen* what the rule matches, styling elements the author explicitly excluded — a much worse failure than not applying at all. `:has()` is **not** forgiving either. Its list was originally specified as forgiving and the CSS Working Group changed it, precisely so that feature detection would work: `@supports selector(:has(a))` can only give a truthful answer if an engine without `:has()` treats the selector as invalid rather than quietly accepting it. ## How to use this deliberately Three practical habits follow. First, when you must group a selector that only some engines know, wrap the group in `:is()` rather than using a comma list. The cost is that `:is()` also imposes its most-specific-argument weight on the group, so keep the arguments comparable in specificity. Second, do not rely on forgiving parsing as a substitute for feature detection. A dropped argument is silent — nothing appears in devtools to say a selector was thrown away — so a genuinely conditional enhancement belongs in `@supports selector(…)`, where the intent is explicit and reviewable. Third, remember that forgiving parsing covers *selectors*, not *declarations*. Declaration-level error handling is separate and already per-declaration: an unknown property or an invalid value drops just that line, leaving the rest of the block intact. The two mechanisms are often conflated in interviews, and being able to separate them cleanly is the mark of someone who has actually read the error-handling rules. ## Why interviewers ask it It is a compact test of whether a candidate understands CSS as a specified language with defined error handling rather than as a bag of properties. The follow-up is almost always "so why isn't `:not()` forgiving too" — and the answer, that dropping a negated argument would broaden the match set instead of narrowing it, shows you can reason about the spec's intent, not just recall the rule.