Détection de la prise en charge du sélecteur CSS

Vous savez peut-être déjà comment nous pouvons utiliser la détection de fonctionnalités dans CSS pour vérifier si une combinaison particulière de propriété et de valeur est prise en charge. C’est une façon assez intelligente d’écrire un CSS robuste qui s’adresse aux utilisateurs avec toute une gamme de navigateurs et d’appareils avec des capacités différentes, et est infiniment préférable au reniflage d’agent utilisateur. Nous pouvons vérifier si un navigateur prend en charge aspect-ratiopar exemple, et fournir une solution de secours dans les cas où le manque de support entraverait l’expérience utilisateur.

.some-element {
  max-height: 200px;
}

@supports (aspect-ratio: 1) {
  .some-element {
    aspect-ratio: 1;
    max-height: none;
  }
}

Ce bloc de code particulier définit une hauteur maximale sur un élément, sauf lorsque aspect-ratio est pris en charge, lorsque nous l’utiliserons à la place.

Nous pourrions rendre cela un peu plus concis en utilisant le not mot-clé, qui inverse essentiellement ce qui précède : nous ne définirons une hauteur maximale que lorsque aspect-ratio est pas prise en charge.

.some-element {
  aspect-ratio: 1;
}

@supports not (aspect-ratio: 1) {
  .some-element {
    max-height: 200px;
  }
}

Le seul problème ici est que les navigateurs très anciens qui ne le faites pas prend en charge les requêtes de fonctionnalités (et ne prend pas en charge aspect-ratio) n’obtiendra pas le repli. C’est beaucoup moins un problème qu’auparavant, étant donné que les requêtes de fonctionnalités sont bien prises en charge depuis un certain temps, mais il convient néanmoins de garder à l’esprit, surtout si beaucoup de vos utilisateurs utilisent des appareils plus anciens.

Cela peut sembler évident, mais cela vaut la peine d’être noté : pour @supports pour évaluer vrai, à la fois le nom de la propriété et la valeur doit être prise en charge. Aucune des expressions entre parenthèses ici n’est valide, ce qui signifie que tous les styles à l’intérieur du @supports déclarations ne seront jamais appliquées :

/* Invalid value for aspect-ratio */
@supports (aspect-ratio: red) {
}

/* Missing value */
@supports (aspect-ratio) {
}

Nous pouvons également combiner des conditions en utilisant le and et or opérateurs, de la même manière que nous pourrions écrire une requête multimédia. Ce qui suit appliquera un rapport d’aspect uniquement lorsque le navigateur prend en charge les deux aspect-ratio et rotate (l’une des nouvelles propriétés de transformation CSS):

@supports (aspect-ratio: 1) and (rotate: 30deg) {
  .some-element {
    aspect-ratio: 1;
  }
}

Détection du support du sélecteur

CSS nous a récemment fourni des sélecteurs plutôt sympas sous la forme de pseudo-éléments et de pseudo-classes. Par exemple, :focus-visible nous permet de styliser un élément lorsqu’il est focalisé avec un clavier. Soutien :has() a récemment atterri dans Chrome et Safari, ce qui nous permet d’appliquer des styles à un élément à la suite de ses enfants.

Heureusement, nous pouvons détecter la prise en charge de ces sélecteurs en utilisant @supportsen préfixant les parenthèses avec selector. Nous pourrions vouloir changer le style de focus du bouton lorsqu’il reçoit le focus d’une souris, mais conserver la bague de focus par défaut lorsqu’il est mis au point avec un clavier, et si le navigateur ne prend pas en charge :focus-visible.

@supports selector(:focus-visible) {
  button:focus:not(:focus-visible) {
    outline: 2px solid limegreen;
  }
}

(Ce sélecteur complexe ne semble pas fonctionner dans Safari pour une raison quelconque, bien que Safari prenne en charge les deux @supports selector() et :focus-visible.)

Vous savez ce que j’ai découvert au cours de la rédaction de cet article ? Les navigateurs ne semblent plus faire cette chose où ils appliquent un anneau de focus à un élément focalisé avec une souris. Je ne sais pas quand cela s’est produit, mais cela semble être un cas primaire pour :focus-visible est maintenant résolu par les navigateurs eux-mêmes 🤷‍♀️

Il semble y avoir une légère différence entre les implémentations de navigateur lors de l’utilisation de pseudo-classes plus complexes telles que :has(): Actuellement, Safari nécessite :has() pour inclure un autre sélecteur, mais Chrome ne le fait pas.

/* This works in Chrome but not Safari */
@supports selector(:has()) {
}

/* This works everywhere */
@supports selector(:has(.some-element)) {
}

Prise en charge du navigateur

@supports selector() est pris en charge dans tous les navigateurs modernes, mais seulement au cours de la dernière année environ. Comme toujours, il vaut la peine de considérer les utilisateurs d’anciens navigateurs et de les utiliser avec précaution dans le cadre de votre stratégie d’amélioration progressive.