A distinction exists between :not(:disabled)
and elements that are neither :enabled
nor :disabled
. This pertains to elements like div
, p
, ul
, etc., where the enabled/disabled semantics do not apply.
The specification acknowledges this:
What defines an enabled or disabled state, as well as a user interface element, is specific to each language. In most documents, the majority of elements will not fall under either :enabled
or :disabled
.
Interestingly, there isn't a corresponding :unchecked
pseudo-class for :checked
, despite not all elements having checked/unchecked semantics either. More on this can be found in my response to this inquiry.
If you add a type selector (like input
, select
, or textarea
) or a class selector to these pseudo-classes, the issue becomes less relevant. Nonetheless, it's advisable to opt for :enabled
over :not(:disabled)
.
Most browsers exhibit identical support for the majority of level 3 pseudo-classes, with none exclusively supporting either :enabled
or :disabled
. However, MDN mentions that Opera 9.0 and Safari 3.1 may not endorse :not()
, even though they do endorse :enabled
and :disabled
. Additionally, IE7 has limited support for substring-matching attribute selectors and the general sibling combinator ~
, with slight improvements in IE8.