Non esiste una tale pseudo-classe. Non ce n'è bisogno, quando puoi semplicemente usare :not(:hover). L'intero punto della :not()pseudo-classe è di consentire agli autori di scrivere negazioni senza dover specificare negazioni separate di ogni pseudo-classe dinamica esistente (e futura) in cui un elemento può solo corrispondere o non corrispondere alla pseudo-classe.
Ad esempio, solo alcuni elementi possono essere :enabledo :disabled- la maggior parte degli elementi non lo sono perché la semantica semplicemente non si applica - ma un elemento può essere designato solo dal dispositivo di puntamento ( :hover) o no ( :not(:hover)). Fornire negazioni che possono essere già ottenute direttamente utilizzando :not()ne minerebbe notevolmente l'utilità (sebbene possa ancora essere utilizzato per negare qualsiasi altro selettore semplice o interi selettori complessi lungo la strada).
L'argomento secondo cui una tale pseudo-classe sarebbe meno costosa dal punto di vista computazionale è piuttosto debole. L'implementazione più ingenua di una simile pseudo-classe sarebbe un :not(:hover)controllo letterale , che non sarebbe migliore. Eventuali implementazioni più complesse o ottimizzate e stai chiedendo ai fornitori di implementare una pseudo-classe che sia veloce quanto o addirittura più veloce di :not(:hover), qualcosa che è già abbastanza raro di un caso d'uso considerando le altre opzioni che hai come cascata e :not(:hover)(per ogni volta che la cascata non è un'opzione) a cui hai prontamente accesso. Semplicemente non giustifica il tempo e lo sforzo per specificare, implementare e testare un'alternativa ad almeno un altro metodo esistente che sia funzionalmente equivalente al 100% (e che si applichi ad almeno80% degli scenari). E c'è anche il problema di nominare una simile pseudo-classe: non hai proposto un nome per questo, e non riesco nemmeno a pensare a uno buono. :not-hoverè solo più corto di due byte e solo marginalmente meno lavoro da digitare. Se non altro, è potenzialmente più confuso di :not(:hover).
Se sei preoccupato per la specificità, nota che la :not()pseudo-classe stessa non viene conteggiata per la specificità; solo il suo argomento più specifico lo è . :not(:hover)e :hoversono ugualmente specifici. Quindi anche la specificità non è un problema.
Se sei preoccupato per il supporto del browser, una tale pseudo-classe, se introdotta, sarebbe stata probabilmente introdotta insieme :not()o in un livello successivo dei Selettori, poiché non appariva in CSS2 (dove è :hoverstata introdotta per la prima volta da più di 17 anni fa, e implementato per la prima volta in IE4 un altro anno prima). Introdurlo a un livello successivo sarebbe inutile perché gli autori sarebbero semplicemente costretti a continuare a usarlo :not(:hover)fino a quando i browser non inizieranno comunque a implementare questa nuova pseudo-classe e non avrebbero motivo di cambiare.
Nota che questa non è la stessa della seguente domanda, che parla di eventi e stati (originariamente si tratta di :focuspiuttosto che :hover, ma si applica lo stesso principio): CSS ha un: blur selector (pseudo-classe)?
element:not(:hover)usaelement.