Browsers currently make no distinction between unrecognized or unsupported selectors, and invalid selectors. If a browser recognizes a selector, generally it'll have implemented it to the best of its ability (and any behavior that's not to spec can be classified as a bug on its bug tracker), even if it doesn't implement all other features in the same level of Selectors (as is currently the case with :dir()
for example, and historically Internet Explorer 7 and 8 with level 3 attribute selectors, and Internet Explorer 6 with the universal selector). If it doesn't recognize the selector, it follows CSS2.1 §4.1.7 to the letter and drops the entire ruleset, no questions asked. Notice that it says
When a user agent cannot parse the selector (i.e., it is not valid CSS 2.1), it must ignore the selector and the following declaration block (if any) as well.
which implies that if a user agent cannot parse a selector, it must therefore be invalid CSS2.1 (or invalid in some other level of Selectors); and inversely that if it can parse a selector, it must therefore be valid. But this assumes the user agent conforms fully to the standard; we all know that in reality, different implementations have different levels of conformance to each standard, and certain implementations even have their own vendor-specific selectors which are not part of any standard. So I treat this as "When a user agent cannot parse the selector" without the parenthetical, and I imagine browser vendors do the same.
In fact, Selectors itself makes no distinction between a pseudo-class token with an ident or function that doesn't correspond to a valid pseudo-class, and a series of characters that cannot even be parsed as a pseudo-class — they're both equally invalid — see section 12 of css3-selectors and section 3.9 of selectors-4. Essentially, this means that the current browser behavior is in full compliance with the standard, and not just an arbitrary decision agreed upon by browser vendors.
I've not heard of any browser that recognizes a pseudo-class as valid for the purposes of error handling, and proceeds to ignore either just that pseudo-class or the entire complex selector (leaving other complex selectors in the selector-list unaffected). WebKit did use to have a really bad habit of accepting CSS rules with unrecognized pseudo-elements, allowing things like ::selection, ::-moz-selection
, which proved useless anyway because every other layout engine followed the spec more strictly. I believe WebKit no longer does this, however, but you know how WebKit is with these things. But AFAIK it has never done this with pseudo-classes.
On the standards side, selectors-4 appears set to change this with the introduction of the static and dynamic profiles. My email on the subject was addressed in a CSSWG telecon; you can find the minutes here (search for "Behavior of Selectors not in Fast Profile"). However, it was resolved that selectors not in the dynamic (previously fast) profile should be treated as invalid and cause the entire CSS rule to be dropped, as usual. See section 2.1:
CSS implementations conformant to Selectors Level 4 must use the dynamic profile for CSS selection. Implementations using the dynamic profile must treat selectors that are not included in the profile as unknown and invalid.