feature query en CSS : tester une propriété avant de l'utiliser

Tous les navigateurs ne comprennent pas les mêmes propriétés CSS au même moment. Une nouveauté comme subgrid ou backdrop-filter peut fonctionner parfaitement sur un navigateur récent tout en étant ignorée sur un navigateur plus ancien, sans le moindre message d'erreur : la ligne est simplement passée sous silence. La feature query sert exactement à ça : demander au navigateur, en CSS pur, s'il comprend telle propriété avant de s'appuyer dessus.

Elle se démarque là où Media query interroge l'écran, sa taille, son orientation : la feature query interroge le moteur de rendu lui-même. C'est l'outil qui permet de proposer une mise en page moderne aux navigateurs récents tout en gardant un affichage correct, quoique plus simple, sur les autres, sans écrire une seule ligne de JavaScript.

Définition

Une feature query est une règle CSS conditionnelle qui commence par @supports et qui n'applique le bloc de styles qu'elle contient que si le navigateur reconnaît la propriété et la valeur testées. Contrairement à une media query, qui réagit à l'environnement d'affichage, la feature query réagit aux capacités du moteur CSS lui-même. Elle permet d'écrire un style moderne en confiance, avec une solution de repli pour les navigateurs qui ne suivent pas encore.

Syntaxe de base

La syntaxe reprend une propriété et une valeur, exactement comme dans une déclaration normale, mais entre parenthèses après @supports. Si le test réussit, le bloc qui suit est appliqué normalement, comme n'importe quelle autre règle CSS.

@supports (display: grid) {
  .conteneur {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
  }
}

En dehors de ce bloc, on écrit généralement un style de repli qui fonctionne partout. Le navigateur qui ne comprend pas grid continue d'utiliser ce repli et n'entre jamais dans le bloc @supports.

Combiner plusieurs conditions

@supports accepte les opérateurs and, or et not, pour composer des conditions plus précises. Cela devient utile quand une fonctionnalité dépend de deux propriétés à la fois, ou quand on veut cibler spécifiquement les navigateurs qui ne suivent pas encore une nouveauté.

@supports (display: grid) and (gap: 1rem) {
  .conteneur {
    display: grid;
    gap: 1rem;
  }
}

@supports not (aspect-ratio: 1 / 1) {
  .vignette {
    padding-top: 100%;
  }
}

Le not est particulièrement pratique pour écrire le repli directement dans son propre bloc @supports, plutôt que de le laisser en dehors de toute condition, où il risquerait d'être écrasé plus tard par erreur.

Exemple concret : mise en page avec repli

Voici un cas fréquent : une grille de cartes qui utilise CSS Grid sur les navigateurs récents, avec un repli en colonnes flexibles pour les autres.

.cartes {
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
}

.cartes > * {
  flex: 1 1 280px;
}

@supports (display: grid) {
  .cartes {
    display: grid;
    grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
  }
}

Le style flexible sert de socle universel. Le bloc @supports vient ensuite le remplacer intégralement sur les navigateurs qui comprennent grid, sans jamais laisser un visiteur avec une page cassée.

Vérifier le support d'une valeur, pas seulement d'une propriété

Un piège fréquent consiste à croire qu'@supports vérifie une propriété seule. En réalité, il faut toujours tester une paire propriété/valeur, car une même propriété peut exister depuis longtemps tout en gagnant de nouvelles valeurs bien plus tard.

/* Incorrect : position existe partout depuis toujours */
@supports (position) {
  .barre {
    position: sticky;
  }
}

/* Correct : on teste la valeur réellement utilisée */
@supports (position: sticky) {
  .barre {
    position: sticky;
  }
}

Cas d'usage courants

Les feature queries sont surtout utiles pour des propriétés récentes ou coûteuses en compatibilité : subgrid, le mode grid lui-même à ses débuts, ou des fonctionnalités comme le filtre d'arrière-plan. Elles servent aussi à documenter une intention dans le code : un développeur qui relit un fichier CSS comprend immédiatement qu'un style est conditionné à une capacité précise du navigateur.

FAQ

Non, le test est évalué une seule fois par le navigateur au chargement de la feuille de style, exactement comme n'importe quelle autre règle CSS : il n'y a aucun coût de performance perceptible à l'usage.

Non, @supports ne teste que des déclarations CSS. Pour détecter une API JavaScript, il faut une vérification côté script, par exemple avec l'objet CSS.supports() qui reproduit la même logique en JavaScript.

Les navigateurs assez anciens pour ignorer @supports ignorent aussi la règle entière, y compris son contenu : ils retombent donc naturellement sur le style écrit en dehors du bloc, ce qui rend cette technique sûre par construction.