Browsers currently do not distinguish between “unrecognized” or “unsupported” selectors and “invalid” selectors. If the browser recognizes the selector, as a rule, it will implement it to the best of its ability (and any behavior that is not related to the specification can be classified as an error in its error debugger), even if it does not implement all other functions at the same level selectors (as is the case with :dir() , for example, and historically IE7 / IE8 with level 3 attribute selectors, and IE6 with a universal selector). If it does not recognize the selector, it follows CSS2.1 §4.1.7 to the letter and discards the entire set of rules, no questions, please note:
When the user agent cannot parse the selector (i.e., it is not valid in CSS 2.1), it should ignore the selector and the next block of declarations (if any).
which implies that if the user agent cannot parse the selector, it must therefore be invalid CSS2.1 (or invalid at some other level of selectors); and vice versa, if it can make out the selector, it must be valid. But this assumes that the user agent is fully compliant; we all know that in fact different implementations have different levels of compliance with each standard, and some implementations have their own selectors specific to suppliers that are not part of any standard. Therefore, I see it as “When the user agent cannot parse the selector” without a bracket, and I believe that browser vendors do the same.
In fact, the selectors themselves do not distinguish between a pseudo-class token with an identifier or function that does not correspond to a valid pseudo-class, and a series of characters that cannot even be analyzed as pseudo-classes - they are both equally invalid - see section 12 of css3 selectors and section 3.9 of selectors -4 . In essence, this means that the current behavior of the browser is fully consistent with the standard, and not just an arbitrary solution agreed by the browser providers.
I have not heard of any browser that recognizes the pseudo-class as valid for error handling, and continues to ignore either this pseudo-class or the entire complex selector (leaving the other complex selectors in the selector, the list is not affected). WebKit really used the very bad habit of accepting CSS rules with unrecognized pseudo-elements, allowing things like ::selection, ::-moz-selection , which turned out to be useless, since every other linking mechanism followed the specification more strictly . I believe WebKit no longer does this, but you know how WebKit is with these things. But AFAIK, he never did this with pseudo-classes.
On the standards side, selectors-4 seem to be configured to change this with the introduction of static and dynamic profiles. My related email was reviewed on the CSSWG TV show; you can find the minutes here (search for "Behavior of selectors not in fast profile"). However, it was decided that selectors outside the dynamic (previously fast) profile should be considered invalid and should force the CSS rule to be completely discarded, as usual. See section 2.1 :
CSS implementations matching Level 4 selectors must use a dynamic profile to select CSS. Implementations that use a dynamic profile must handle selectors that are not included in the profile as unknown and invalid.