Is there an opposite CSS pseudo-class to :hover?

Is there a pseudo-class in CSS to specify

:not(:hover)

Or is that the only way to specify an item that is not being hovered?

I went through several CSS3 references, and I see no mention of a CSS pseudo-class to specify the opposite of :hover.

Solution 1:

Yes, use :not(:hover)

.child:not(:hover){
  opacity: 0.3;
}

.child {
  display: inline-block;
  background: #000;
  border: 1px solid #fff;
  width: 50px;
  height: 50px;
  transition: 0.4s;
}

.child:not(:hover) {
  opacity: 0.3;
}

<div class="parent">
  <div class="child"></div>
  <div class="child"></div>
  <div class="child"></div>
  <div class="child"></div>
  <div class="child"></div>
</div>

Another example; I think you want to: "when one is hovered, dim all other elements".

If my assumption is correct, and assuming all your selectors are inside the same parent:

.parent:hover .child{
  opacity: 0.2;      // Dim all other elements
}
.child:hover{
  opacity: 1;        // Not the hovered one
}

.child {
  display: inline-block;
  background: #000;
  border: 1px solid #fff;
  width: 50px;
  height: 50px;
  transition: 0.4s;
}

.parent:hover .child {
  opacity: 0.3;
}

.parent .child:hover {
  opacity: 1;
}

<div class="parent">
  <div class="child"></div>
  <div class="child"></div>
  <div class="child"></div>
  <div class="child"></div>
</div>

Otherwise... simply use the default logic:

.child{
  opacity: 0.2;
}
.child:hover{
  opacity: 1;
}

Solution 2:

There isn't such a pseudo-class. There doesn't need to be, when you can just use :not(:hover). The whole point of the :not() pseudo-class is to allow authors to write negations without having to specify separate negations of every existing (and future) dynamic pseudo-class where an element can only either match or not match the pseudo-class.

For example, only some elements can either be :enabled or :disabled — most elements are neither because the semantics simply don't apply — but an element can only either be designated by the pointing device (:hover), or not (:not(:hover)). Providing negations that can already directly be achieved using :not() would greatly undermine its usefulness (though it could still be used to negate any other simple selector — or entire complex selectors down the road).

The argument that such a pseudo-class would be computationally less expensive is pretty weak. The most naïve implementation of such a pseudo-class would be a literal :not(:hover) check, which would be no better. Any more complex or optimized implementations and you're asking vendors to implement a pseudo-class that is either as fast as or even faster than :not(:hover), something that's already uncommon enough of a use case considering the other options you have such as cascading and :not(:hover) (for whenever cascading isn't an option) that you readily have access to. It simply doesn't justify the time and effort to spec, implement and test an alternative to at least one other existing method that is 100% functionally equivalent (and one that applies to at least 80% of scenarios). And there's also the issue of naming such a pseudo-class — you haven't proposed a name for it, and I can't think of a good one either. :not-hover is only shorter by two bytes and only marginally less work to type. If anything, it's potentially more confusing than :not(:hover).

If you are worried about specificity, note that the :not() pseudo-class itself is not counted for specificity; only its most specific argument is. :not(:hover) and :hover are equally specific. So specificity is not an issue either.

If you are worried about browser support, such a pseudo-class, if introduced, would likely have either been introduced alongside :not(), or in a later level of Selectors, since it didn't appear in CSS2 (where :hover was first introduced more than 17 years ago, and first implemented in IE4 another year yet before). Introducing it in a later level would be pointless because authors would simply be forced to continue using :not(:hover) until browsers begin implementing this new pseudo-class anyway, and they would have no reason to switch.

Note that this isn't the same as the following question, which talks about events vs states (it's originally about :focus rather than :hover, but the same principle applies): Does CSS have a :blur selector (pseudo-class)?