Il n'y a pas une telle pseudo-classe. Il n'y en a pas besoin, quand vous pouvez simplement utiliser :not(:hover)
. L'intérêt de la :not()
pseudo-classe est de permettre aux auteurs d'écrire des négations sans avoir à spécifier des négations séparées de chaque pseudo-classe dynamique existante (et future) où un élément ne peut correspondre qu'à la pseudo-classe ou non.
Par exemple, seuls certains éléments peuvent être :enabled
ou :disabled
- la plupart des éléments ne sont ni l'un ni l'autre car la sémantique ne s'applique tout simplement pas - mais un élément ne peut être désigné que par le dispositif de pointage ( :hover
), ou non ( :not(:hover)
). Fournir des négations qui peuvent déjà être obtenues directement en utilisant :not()
compromettrait considérablement son utilité (bien qu'il puisse toujours être utilisé pour annuler tout autre sélecteur simple - ou des sélecteurs complexes entiers sur la route).
L'argument selon lequel une telle pseudo-classe serait moins coûteuse en calcul est assez faible. L'implémentation la plus naïve d'une telle pseudo-classe serait une :not(:hover)
vérification littérale , ce qui ne serait pas mieux. Des implémentations plus complexes ou optimisées et vous demandez aux fournisseurs d'implémenter une pseudo-classe qui est soit aussi rapide, soit même plus rapide que :not(:hover)
, quelque chose qui est déjà assez rare d'un cas d'utilisation compte tenu des autres options que vous avez telles que la cascade et :not(:hover)
(pour chaque fois que la cascade n'est pas une option) auquel vous avez facilement accès. Cela ne justifie tout simplement pas le temps et les efforts nécessaires pour spécifier, implémenter et tester une alternative à au moins une autre méthode existante qui est fonctionnellement équivalente à 100% (et qui s'applique à au moins80% des scénarios). Et il y a aussi le problème de nommer une telle pseudo-classe - vous n'avez pas proposé de nom pour cela, et je ne peux pas penser à un bon non plus. :not-hover
est seulement plus court de deux octets et peu de travail à taper. Si quoi que ce soit, c'est potentiellement plus déroutant que :not(:hover)
.
Si vous êtes préoccupé par la spécificité, notez que la :not()
pseudo-classe elle-même n'est pas comptée pour la spécificité; seul son argument le plus spécifique est . :not(:hover)
et :hover
sont tout aussi spécifiques. La spécificité n'est donc pas non plus un problème.
Si vous vous inquiétez de la prise en charge du navigateur, une telle pseudo-classe, si elle avait été introduite, aurait probablement été introduite parallèlement :not()
ou à un niveau ultérieur de sélecteurs, car elle n'apparaissait pas dans CSS2 (où elle a :hover
été introduite pour la première fois plus de 17 ans) il y a, et mis en œuvre pour la première fois dans IE4 un an auparavant). L'introduire à un niveau ultérieur serait inutile car les auteurs seraient simplement obligés de continuer à utiliser :not(:hover)
jusqu'à ce que les navigateurs commencent à implémenter cette nouvelle pseudo-classe de toute façon, et ils n'auraient aucune raison de changer.
Notez que ce n'est pas la même chose que la question suivante, qui parle d'événements vs états (il s'agit à l'origine :focus
plutôt que de :hover
, mais le même principe s'applique): Le CSS a-t-il un sélecteur: blur (pseudo-classe)?
element:not(:hover)
Utilisez plutôtelement
.