@media - Directive CSS

Description de la directive @media.

@media est une directive existant depuis longtemps dans le langage CSS. Elle a cependant été considérablement enrichie avec les requêtes-média (media-queries). Elle permet d'appliquer des styles en fonction des possibilités du terminal sur lequel la page est consultée.

L'exemple ci-dessous applique des marges nulles à gauche et à droite si l'écran utilisé est plus haut que large (portait).

Dans sa définition initiale, @media permettait seulement de cibler le périphérique en fonction de son type : imprimante, écran, smartphone, etc. En utilisant cette directive, il était donc possible de définir des mises en page spécifiques à chaque type de périphérique. Cette solution a néanmoins été abandonnée car elle manquait de précision. En effet un écran de smartphone a parfois autant de définition qu'un écran de bureau. Et de nombreuses autres caractéristiques sont souvent nécessaires : présence d'un pointeur précis (souris, tablette), nombre de couleurs que l'écran peut restituer, etc.

Depuis CSS3 la directive @media a été enrichie et permet maintenant de cibler un périphérique de façon beaucoup plus précise, en fonction de ses possibilités. On parle alors de media-query.

Ciblage du périphérique par son type. ✗

Rappelons que ces syntaxes sont déconseillées à l'heure actuelle.

Voici à quoi ressemble une feuille de styles utilisant des directives @media pour appliquer des mises en forme différentes sur l'écran et à l'impression. Notez le niveau d'accolades supplémentaire.

Remarque : il est possible aussi de créer une feuille de styles séparées pour chaque média, et de préciser ensuite le type de périphérique dans la balise link du code HTML :

Ciblage du périphérique d'après ses caractéristiques : les requêtes-média (media-queries).

De nombreuses caractéristiques peuvent être précisées : les dimensions, le nombre de couleurs restituables, la présence d'une souris, etc. On peut par exemple écrire un directive pour cibler les terminaux avec un écran supérieur à 900 pixels de large.

Dans leur première version, les requêtes-média n'acceptaient pas les signes inférieur et supérieur ( < > ), ceci afin d'éviter des conflits éventuels avec la syntaxe du HTML. Les conditions s'écrivaient avec les préfixes min- ou max- avant le nom de la propriété.
On écrivait par exemple min-width:900px au lieu de width > 900px. Mais cette notation n'était pas très lisible et était la cause de nombreuses confusions. Heureusement il est maintenant possible d'utiliser < et > dans la syntaxe des media-queries.

D'autre part, pour rester compatible avec les navigateurs anciens, ne reconnaissant que le périphérique mais pas la syntaxe complète des media-queries, on peut encore préciser le type de périphérique avant le critère. Ainsi pour spécifier un écran de plus de 900 pixels de large, on écrit :

Cette syntaxe est toujours valide et reste recommandée s'il est nécessaire d'assurer la compatibilité avec des navigateurs pas trop récents. Mais il est de plus en plus courant d'utiliser la syntaxe moderne :

Ancienne syntaxes pour le ciblage du type de périphérique.

• @media all { ... } @media screen { ... } @media print { ... }

  Ces syntaxes correspondent à la définition initiale de la directive @media. Elles permettent simplement de spécifier un type de périphérique (media type).

  • all : les règles s'appliquent à tous les périphériques. C'est la valeur par défaut.
  • screen : désigne les écrans. Les règles entre les accolades s'appliquent lorsque les pages sont visionnées sur un ordinateur de bureau, sur un téléphone, une tablette, etc.
  • print : désigne les imprimantes. Les règles entre les accolades s'appliquent lorsque les pages sont imprimées ou affichées en aperçu avant impression.
• @media tty { ... } ✗ @media tv { ... } ✗ @media projection { ... } ✗ @media handled { ... } ✗ @media braille { ... } ✗ @media embossed { ... } ✗ @media aural { ... } ✗ @media speech { ... } ✗

  Ces types de périphériques sont maintenant obsolètes. Ne les utilisez plus.

  • tty : terminaux ne pouvant imprimer que des caractères de largeur fixe.
  • tv : téléviseurs.
  • projection : projecteurs vidéo.
  • handled : terminaux de petite taille, pouvant être utilisé tenu à la main.
  • braille : terminaux permettant la restitution en braille.
  • embossed : terminaux d'impression en braille.
  • aural ou speech : terminaux avec restitution sonore.

Syntaxes générales des requêtes media queries.

La syntaxe complète des media queries permet de cibler un périphérique de façon beaucoup plus fine que simplement son type : on peut cibler le périphérique à partir de ses caractéristiques (media features) comme la résolution, sa capacité à restituer les couleurs, la présence d'une souris, etc.

Liste des caractéristiques (features) disponibles :

• @media (width >= 900px) { ... } @media (min-width:900px) { ... } @media screen and (min-width:900px) { ... }

  Comparaison à une valeur numérique.

  Toutes ces syntaxes sont équivalentes et ciblent les périphériques dont la définition en largeur est supérieure ou égale à 900 pixels. La première syntaxe, la plus récemment définie, est la plus lisible. Elle est maintenant bien reconnue et peut être utilisée sans gros risque de compatibilité avec les navigateurs actuels. Reportez-vous cependant à tableau de compatibilité figurant au bas de cette page.

  On remarque que toutes les valeurs sont suivies d'une unité, qui sont les unités habituelles en CSS (voir les unités de dimension). On évitera cependant d'utiliser les unités relatives, qui n'ont pas beaucoup de sens dans ce contexte, mais qui sont néanmoins acceptées par la syntaxe. Elles sont alors déterminées par rapport à la valeur initiale : par exemple l'unité em est calculé par rapport par rapport à la valeur initiale de la propriété font-size.

  La condition doit être inscrite entre parenthèses.

  Dans quelques cas, il suffit d'indiquer le nom de la caractéristique, sans préciser de valeur. Par exemple (color) cible les périphériques capables de restituer les couleurs, en excluant les périphériques monochromes.

  Si une condition fait référence à une caractéristique inexistante sur le périphérique concerné, la requête media query est fausse. Par exemple une condition sur le pointeur (souris) alors que le périphérique est une imprimante, rend l'ensemble de la requête faux : les styles ne sont pas appliqués.

• @media (900px <= width <= 1200px) { ... } @media (width >= 900px) and (width <= 1200px) { ... } @media (min-width:900px) and (max-width:1200px) { ... }

  Fourchette de valeurs.

  Les trois syntaxes ci-dessus sont équivalentes, et ciblent les périphériques dont la définition horizontale est comprise entre 900 pixels et 1200 pixels, bornes incluses. La première syntaxe est naturellement beaucoup plus claire puisqu'il est possible de définir une fourchette en une seule écriture.

• @media (orientation: portrait) { ... }

  Comparaison à une valeur prédéfinie.

  Certaines caractéristiques ne sont pas exprimées en valeurs numériques. Dans notre exemple, l'orientation peut être portrait ou landscape. Les opérateurs > et < n'ont pas de signification dans ce cas de figure. De même les syntaxes avec les préfixes min- et max- ne sont pas possibles avec les caractéristiques non numériques : min-orientation n'a pas de sens.

  La syntaxe utilise ici le caractère deux points. Attention à ne pas utiliser le signe égal, qui serait pourtant plus intuitif puisque les opérateurs <= et >= sont eux reconnus.

• @media (width >= 1200px) and (height >= 900px) { ... } @media (width >= 1200px), (height >= 900px) { ... } @media (width >= 1200px) or (height >= 900px) { ... }

  Combinaison de plusieurs conditions.

  Les conditions multiples peuvent être associées par un ET logique. dans ce cas le mot and doit être précisé, ou par un OU logique, qui se traduit par une virgule entre les critères ou par le mot or. Dans tous les cas, chacune des conditions doit se trouver entre parenthèses.

  Si le mot or est utilisé à la place de la virgule, et que l'écriture fait intervenir à la fois des and et des or; il faudra obligatoirement préciser l'ordre de traitement en utilisant des parenthèses.

  @media (height < 900px) and (width < 900px) or (width > 1000px) est incorrect @media (height < 900px) and ((width < 900px) or (width > 1000px)) est correct
• @media not (width >= 1200px) { ... } @media not (width >= 1200px), (height >= 900px) { ... }

  Inversion d'une condition.

  Le mot not est l'opérateur de négation habituel. Notre premier exemple cible les périphériques dont la définition horizontale est inférieure à 1200 pixels.

  Dans le deuxième exemple, il faut noter que la négation ne s'applique que à la première condition. Il cible donc les périphériques dont la définition horizontale est inférieure à 1200 pixels et également ceux dont la définition verticale est supérieure à 900 pixels (la négation ne s'applique pas sur cette deuxième requête).

  Le mot not doit obligatoirement être suivi par un espace avant la parenthèse ouvrante, pour éviter la confusion avec une fonction.

• @media only print and (monochrome) { ... }

  Le mot-clé only.

  Le mot only avait été défini pour assurer la compatibilité avec les anciens navigateurs, qui ne reconnaissent que le type de média (print) et pas la media queries qui suit (monochrome).
  Sans cette précaution, les anciens navigateurs risquent d'appliquer à tord les styles à toutes les imprimantes, même celles qui ne sont pas monochromes.

  Le mot only, ajouté avant le type de périphérique, est interprété par les anciens navigateurs comme un périphérique inconnu et empêche l'application à tord des styles à toutes les imprimantes.
  only est neutre pour les navigateurs plus modernes qui traient la syntaxe complète des media queries.

  Cependant, cette précaution est maintenant inutile compte-tenu du fait que pratiquement tous les navigateurs reconnaissent la syntaxe complète des media queries.

Requêtes media queries pour évaluer les dimensions du périphérique.

• @media (width < 21cm) { ... } @media {height < 29.7cm) { ... } @media (device-width < 21cm) { ... } ✗ @media {device-height < 29.7cm) { ... } ✗

  Les deux conditions width et height correspondent à la largeur et à la hauteur du viewport s'il s'agit d'un périphérique à défilement continu comme un écran, ou aux dimensions de la boîte de page s'il s'agit d'un périphérique paginé comme une imprimante.

  width et height peuvent être comparées à n'importe quelle valeur suivie d'une unité de dimension (voir les unités de dimension). Notre exemple utilise des centimètres, ce qui est courant pour caractériser une imprimante ; pour un écran on utilisera plutôt des pixels.

  Les anciens termes device-width et device-height ne doivent plus être utilisés.

• @media (aspect-ratio > 1) { ... } @media (device-aspect-ratio > 1) { ... } ✗

  La ratio est calculé par la formule : largeur divisé par hauteur. Cette information permet de déterminer l'orientation (voir ci-après) et la forme de l'écran. En particulier, un ratio de 1 indique un écran carré, comme celui d'une montre connectée.

  Le terme device-aspect-ratio est obsolète et ne doit plus être utilisé, bien que certains navigateurs le reconnaissent encore pour des raisons de compatibilité.

• @media (orientation: portrait) { ... }

  orientation ne peut prendre que deux valeurs : portrait ou paysage. Les opérateurs < et > ne sont donc pas acceptés avec orientation.

  L'orientation est déterminée sur paysage dès la largeur est supérieure ou égale à la hauteur. Un écran carré, comme celui d'une montre, aura donc une orientation en paysage.

  Sur un terminal mobile comme un téléphone, orientation permet de déterminer si l'appareil est tenu verticalement ou horizontalement.

Requêtes media queries pour évaluer la qualité de la restitution.

• @media (resolution > 300dppx) { ... }

  Cette requête media queries cible les périphériques en fonction de la résolution de l'écran, c'est à dire le nombre de pixels sur une distance donnée. La plupart du temps la résolution d'un écran est la même horizontalement et verticalement ; si ce n'est pas le cas, c'est la résolution verticale qui est prise en compte.

  La valeur comparée à resolution doit être suivie d'une unité de résolution comme par exemple dpi (Dot Per Inch ou Points par pouce). Voir les unités de résolution.

  La valeur infinite peut être utilisée, elle correspond aux périphériques qui ne sont pas pixelisés, comme par exemple les traceurs.

Requêtes media queries pour évaluer la technologie de terminal.

La diversification de plus en plus importante des périphériques nécessite de pouvoir tester la technologie utilisée : écran cathodique (en voie de disparition), écran LCD, imprimante, traceur, panneau d'affichage, montre connectée, système pour la réalité augmentée, etc.

• @media (scan: interlace) { ... }

  Cette requête media queries cible les périphériques en fonction du type de balayage de l'écran. Elle permet de distinguer les écrans cathodiques des écrans à LCD modernes. Cependant les écrans cathodiques sont devenus très rares à l'heure actuelle. Certaines polices de caractères sont mal restituées sur les écrans entrelacés, en particulier les polices avec empattements.

  Les valeurs possibles sont :

  • interlace : les écrans cathodiques fonctionnent sur ce principe, qui permet de diminuer le scintillement, donc la fatigue visuelle. Cela consiste à tracer les lignes paires lors d'un premier balayage, et les lignes impaires lors du balayage suivant.
  • progressive : tous les écrans actuels (LCD) fonctionnent sur ce principe.
• @media (grid) { ... }

  Cette syntaxe détecte si l'écran reconstitue les caractères à partir d'une matrice de points de dimensions fixes. Plus aucun écran ne fonctionne comme ça : cette requête renvoie toujours faux.

• @media (update: slow) { ... }

  Cette requête media queries cible les écrans en fonction de leur capacité à mettre à jour le contenu après le premier affichage. Très utile pour décider si les animations peuvent être activées ou non. De même les réactions aux actions de l'utilisateur (pseudo-classe :hover) risquent d'être mal rendues sur un écran trop lent.

  Les valeurs acceptées sont :

  • none : La mise à jour n'est plus possible après la première restitution. C'est le cas des imprimantes par exemple.
  • slow : le rafraîchissement de l'écran est possible mais lent.
  • : le rafraîchissement de l'écran est suffisamment rapide pour restituer les animations.

  La valeur peut être omise. Dans ce cas (update) indique qu'une mise à jour est possible mais sans donner d'information sur sa rapidité.

• @media (overflow-block: none) { ... } @media (overflow-inline: none) { ... }

  Ces deux media queries ciblent les périphériques en fonction de leur comportement en cas de débordement du contenu. Pour overflow-block il s'agit d'un débordement dans la direction des blocs, c'est à dire le sens vertical pour les langues latines), et pour overflow-inline ce sera le débordement dans la direction des lignes.

  Les valeurs possibles pour overflow-block sont :

  • none : le débordement est impossible. Le contenu excédentaire n'est pas affiché, comme par exemple sur un panneau d'affichage électronique.
  • scroll : le contenu excédentaire est affiché en dehors de la zone visible ; le lecteur peut le consulter en faisant défiler. C'est le cas des écrans.
  • paged : le contenu excédentaire est rejeté sur une nouvelle page. C'est le cas des imprimantes.

  Si la valeur est omise (overflow-block) indique qu'un débordement est possible mais indiquer le type de débordement.

  Pour overflow-inline, les valeurs possibles sont :

  • none : le contenu excédentaire n'est pas affiché, et il n'y a pas de moyen pour l'utilisateur de le faire apparaître.
  • scroll : le lecteur peut faire apparaître le contenu excédentaire en faisant défiler l'écran (présence de barres de défilement par exemple.

  Si la valeur est omise (overflow-inline) est équivalent à (overflow-inline: scroll).

Requêtes media queries concernant la gestion des couleurs.

• @media (color) { ... } @media (color > 24) { ... }

  Cette requête media queries permet d'évaluer la capacité du périphérique à restituer les couleurs. La première syntaxe détermine seulement si le périphérique est en couleurs ou non. La deuxième permet de tester le nombre de bits réservés à chaque couleur. Si le périphérique est monochrome, le nombre de bits est 0.

  Si la première syntaxe est intéressante pour distinguer par exemple une imprimante en couleurs d'une imprimante noir et blanc, la deuxième ne donne pas une information très précise sur la gestion des couleurs du périphérique. Il sera sans doute plus intéressant d'utiliser color-gamut (voir plus loin).

• @media (color-index > 128) { ... }

  Cette requête media queries permet de cibler les périphériques qui gèrent des couleurs indexées. La valeur indiquée correspond au nombre de couleurs dans l'index. Si le périphérique ne gère pas les couleurs par un index, la valeur est 0.

• @media (monochrome) { ... } @media (monochrome >= 4) { ... }

  La première syntaxe cible les périphériques monochromes. La deuxième est plus précise : elle cible les périphériques monochromes qui gèrent le gris avec au minimum 4 bits par pixels (16 niveaux de gris).

• @media (color-gamut: p3) { ... }

  Cette syntaxe cible les périphériques capables de restituer l'espace de couleurs p3. Reportez-vous si nécessaire à cette présentation des espaces de couleurs. color-gamut permet d'envoyer les images qui correspondent le mieux aux capacités du périphérique.

  Les principales valeurs acceptées sont :

  • srgb : le périphérique est capable de restituer à peu près toutes les couleurs de l'espace srgb, ce qui à l'heure actuelle, devrait être toujours le cas, cet espace de couleurs étant le moins exigeant, sauf bien sûr s'il s'agit d'un périphérique monochrome.
  • p3 : espace de couleurs plus large que sRGB.
  • rec2020 : espace de couleurs encore plus large que p3.

  color-gamut peut être vrai sur plusieurs valeurs. Par exemple si un écran supporte l'espace rec2020, il supportera également le p3 et le sRGB. Pour cette raison, il faudra prendre soin d'écrire les directives @media dans l'ordre croissant (en commençant par srgb et en terminant par l'espace de couleurs le plus étendu).

• @media (dynamic-range: high) { ... }

  dynamic-range caractérise le contraste maximal que peut restituer un écran. Cette caractéristique se décompose en trois :

  • La luminosité maximale.
  • Le contraste maximal, c'est à dire le ratio entre la luminosité maximale et la luminosité minimale que le systéme est capable de restituer.
  • La profondeur de couleur, autrement dit le nombre de bits utilisées pour coder les couleurs.

  Les valeurs possibles sont :

  • high : le périphérique supporte les fortes luminosités et les forts contrastes. D'autre part, les couleurs sont représentées sur au moins 24 bits.
  • standard : tous les périphériques, même ceux qui ne présentent pas les caractéristiques décrites ci-dessus.
• @media (inverted-colors: inverted) { ... }

  Une inversion des couleurs peut se produire par exemple lorsque l'utilisateur bascule son terminal en mode nuit. inverted-colors ne réagit pas lorsque l'inversion est due à une règle de la feuille de styles.

  Les valeurs possibles pour inverted-colors sont :

  • none : lorsque les couleurs sont affichées normalement.
  • inverted : les couleurs s'affichent inversées (les tons clairs sont sombres, et vice-versa).

  La valeur peut être omise : (inverted-colors) est équivalent à (inverted-colors:inverted).

  Si l'inversion des couleurs améliore la lisibilité du texte dans certaines conditions, elle pose un problème avec les images et les vidéos car ces éléments se retrouvent eux aussi affichés en négatif. Pour compenser ce problème, les navigateurs comportent en principe le code ci-dessous dans leur feuille de styles intégrée :

  @media (inverted-colors) { img, video { filter: invert(100%); } }
• @media (video-color-gamut: srgb) { ... }

  Cette requête media queries a le même rôle que color-gamut mais s'applique aux vidéos. Les valeurs possibles sont également les mêmes : srgb, p3, etc.

• @media (video-dynamic-range: hight) { ... }

  Les valeurs et le rôle de video-dynamic-range sont les mêmes que pour dynamic-range mais s'appliquent plus spécialement aux vidéos.

• @media (horizontal-viewport-segments: 2) { ... } @media (vertical-viewport-segments: 2) { ... }

  Il arrive que l'écran soit physiquement divisé en plusieurs parties. C'est le cas par exemple des téléphones pliables comportant une charnière au milieu de l'écran, ou des écrans immenses utilisés en événementiel, et qui sont composés de plusieurs écrans juxtaposés.

• @media (display-mode: fullscreen) { ... }

  Cette requête media queries permet de cibler les applications en fonction de leur mode d'affichage.
  Les valeurs possibles sont :

  • fullscreen : plein écran. Cet affichage est accessible sous Windows avec la touche F11. Tout ce qui n'est pas la page elle même est masqué : barre de menus, barre d'outils, barre d'adresse, titre de la fenêtre, etc.
  • standalone ; la page est affichée comme si elle était une application. Les accessoires spécifiques à la navigation web sont masques (barre d'adresse, boutons de navigation...) mais les éléments du système sont affichés (titre des fenêtres par exemple).
  • minimal-ui : semblable à standalone mais quelques éléments permettant la navigation sont affichés.
  • browser : affichage classique de la page dans un navigateur.
• @media (environment-blending: opaque) { ... }

  Littéralement cette requête media queries permet de tester comment l'affichage se mélange avec l'environnement réel. Par exemple, les écrans d'aide à la conduite dans une voiture sont transparents et superposent leur affichage à la vision de l'environnement. Plus généralement, cela concerne toutes les applications en réalité augmentée.

  Les valeurs acceptées sont :

  • opaque : l'écran n'est pas transparent.
  • additive : l'écran est transparent et superpose son affichage à la vision réelle. Le noir est restitué comme transparent.
  • subtractive : l'écran "soustrait" son affichage de la vision réelle : c'est le blanc qui est sans effet car rendu comme transparent. Ce type d'affichage correspond par exemple à un afficheur intégré à un miroir.

Requêtes media queries pour la détection du pointeur.

• @media (pointer: fine) { ... } @media (any-pointer: fine) { ... }

  Ces deux syntaxes permettent de tester la présence d'un pointeur du genre souris, trackball, etc. pointer ne considère que le pointeur principal, tandis que any-pointer prend en compte tous les périphériques de pointage lorsqu'il y en a plusieurs.

  Les valeurs possibles pour pointer et any-pointer sont :

  • none : aucun périphérique de pointage n'est disponible.
  • coarse : un périphérique est disponible mais il est imprécis, et ne permet pas de cliquer sur de petits éléments.
  • fine : un périphérique de pointage précis est disponible.

  La valeur peut être omise. Dans ce cas (pointer) indique la présence d'un périphérique de pointage, sans qu'il soit possible de savoir s'agit d'un périphérique de pointage précis ou grossier.

  Voici un exemple de code qui garanti une taille minimale pour les boutons lorsque le périphérique de pointage est imprécis :

  @media (pointer:coarse) { input[type='button'], button { min-with: 100px; min-height:50px; } }
• @media (hover: none) { ... } @media (any-hover: none) { ... }

  Ces deux syntaxes permettent de tester la possibilité pour le terminal de détecter le survol d'un élément. Une souris classique par exemple permet de survoler un élément sans le cliquer. Par contre sur un écran de téléphone portable, il n'est pas possible de détecter le doigt avant qu'il ne touche l'écran. Cette requête-média permet de décider s'il est pertinent d'utiliser la pseudo-classe :hover.

  Les valeurs possibles pour hover et any-hover sont :

  • none : la détection du survol n'est pas possible. C'est le cas si le périphérique est un téléphone portable par exemple.
  • hover : le survol est détectable. Ce sera le cas de tous les terminaux comportant une souris ou un périphérique comparable.

  La valeur peut être omise. Dans ce cas (hover) est équivalent à (hover:hover) et (any-hover) est équivalent à (any-hover:hover).

• @media (nav-controls: none) { ... }

  Cette requête media queries permet de détecter si le navigateur propose des accessoires de navigation visuels, comme par exemple un bouton pour revenir sur la page précédente. Les raccourcis clavier ne sont pas concernés. Sur un téléphone portable, les gestes ayant un rôle particulier ne sont pas concernés non plus (comme de glisser vers la gauche pour revenir sur la page précédente).

  nav-controls est intéressant dans le cas où une page web nécessite impérativement des boutons pour naviguer entre les pages, et que cette page peut être incrustée dans une application qui n'est pas un navigateur et qui ne propose pas forcément ces accessoires de navigation.

  Les valeurs possibles pour hover et any-hover sont :

  • none : l'application qui affiche la page ne propose pas d'accessoires de navigation.
  • back : l'application qui affiche la page propose au moins un bouton de retour sur la page précédente.

  La valeur peut être omise. Dans ce cas (nav-controls) est équivalent à (nav-controls:back).

  Exemple : faire disparaître le bouton de retour prévu sur la page, lorsque le navigateur propose son propre bouton de retour :

  @media (nav-controls: back) { #bouton-retour {display:none;} }

Préférences de l'utilisateur.

De nombreuses options pour améliorer la lisibilité sont proposées par les systèmes d'exploitation. L'utilisateur peut activer ou non ces options. D'autres paramètres peuvent être ajustés automatiquement par le système ou par le navigateur : par exemple lorsque la lumière ambiante est faible, le thème de couleurs "dark" est généralement activé. A l'inverse, dans une forte lumière ambiante, le contraste est augmenté pour faciliter la lecture.

Les requêtes media queries qui suivent permettent au développeur de styles de prendre ces paramètres en compte.

• @media (forced-colors: active) { ... }

  forced-colors teste si le mode d'affichage à contraste élevé est activé dans le système d'exploitation. Dans ce mode les couleurs sont modifiées pour offrir toujours un contraste maximal et une lisibilité accrue.

  Les valeurs possibles pour forced-colors sont :

  • none : lorsque le mode d'affichage choisi est normal.
  • active : lorsque le mode d'affichage choisi est à fort contraste.

  La valeur peut être omise : (forced-colors) est équivalent à (forced-colors:active).

• @media (prefers-color-scheme: dark) { ... }

  Cette requête media queries permet de connaître le thème de couleurs choisi par l'utilisateur.

  Les valeurs possibles pour prefers-color-scheme sont :

  • light : l'utilisateur a choisi un thème clair.
  • dark : l'utilisateur a choisi un thème foncé.

  La spécification du W3C précise que de nouvelles valeurs pourront être définies dans l'avenir. En conséquence il est recommandé de ne pas considérer light et dark comme deux valeurs opposées. S'il est nécessaire d'écrire des styles lorsque le thème dark est choisi, et des styles dans le cas contraire, utiliser l'opérateur not.

  @media (prefers-color-scheme: dark) { ... styles ... } @media not (prefers-color-scheme: dark) { ... styles ... }
• @media (prefers-contrast: less) { ... }

  Cette requête media queries teste si l'utilisateur a choisi une valeur pour le contraste (ou s'il n'est pas intervenu sur ce réglage).

  prefers-contrast peut prendre les valeurs :

  • no-preference : l'utilisateur n'a pas changé la valeur du contraste.
  • less : l'utilisateur a demandé une réduction des contrastes.
  • more : l'utilisateur a demandé un renforcement des contrastes.
  • custom : l'utilisateur a demandé une valeur de contraste particulière.

  La valeur peut être omise. Dans ce cas (prefers-contrast) indique que l'utilisateur a modifié la valeur des contrastes, mais sans préciser s'il d'une augmentation ou d'une diminution.

• @media (prefers-reduced-data: reduce) { ... }

  Cette requête media queries teste si l'utilisateur a opté pour une réduction du volume de données à transférer. Dans ce cas il est recommandé de proposer un contenu alternatif plus économique en volume de données.

  Les valeurs possibles pour prefers-reduced-data sont :

  • no-preference : l'utilisateur n'a pas opté pour une réduction du volume de données.
  • reduce : l'utilisateur a demandé à ce que le volume de données transférées soit réduit.

  La valeur peut être omise. Dans ce cas (prefers-reduced-data) est équivalent à (prefers-reduced-data:reduce).

  Exemple. Lorsqu'il est demandé de réduire le volume de données, l'image d'arrière-plan de la page n'est pas affichée :

  body {background-image:url('...'); @media (prefers-reduced-data) { body {background-image:none;} }
• @media (prefers-reduced-motion: reduce) { ... }

  Cette requête media queries teste si l'utilisateur a opté pour une limitation des animations.

  Les valeurs possibles pour prefers-reduced-motion sont :

  • no-preference : l'utilisateur n'a pas opté pour une réduction des animations.
  • reduce : l'utilisateur a demandé à ce que les animations soient réduites.

  La valeur peut être omise. Dans ce cas (prefers-reduced-motion) est équivalent à (prefers-reduced-motion:reduce).

• @media (prefers-reduced-transparency: reduce) { ... }

  Cette requête media queries teste si l'utilisateur a opté pour une limitation des effets de transparence ou translucidité.

  prefers-reduced-transparency peut prendre les valeurs :

  • no-preference : l'utilisateur n'a pas opté pour une réduction des animations.
  • reduce : l'utilisateur a demandé à ce que les animations soient réduites.

  La valeur peut être omise. Dans ce cas (prefers-reduced-transparency) est équivalent à (prefers-reduced-transparency:reduce).

Compatibilité des navigateurs avec la directive @media.

La première colonne du tableau ci-dessous concerne l'utilisation de @media pour cibler un type de périphérique (écran, imprimante...). Cette utilisation est bien prise en charge par tous les navigateurs actuels.
C'est également le cas pour le traitement des requêtes-média complètes, avec ciblage du périphérique d'après ses caractéristiques (2ème colonne).

Les colonnes suivantes concernent des requêtes-média particulières comme resolution, pointer ou hover.

Colonne 1

Support des requêtes @media dans leur ancienne syntaxe : ciblage d'un périphérique à partir de son type : print par exemple. Cette méthode manque de précision et n'est plus recommandée par le W3C.

Colonne 2

Support par les navigateurs de la directive @media pour cibler un périphérique à partir de ses caractéristiques : dimensions, résolution, orientation, etc.

Colonne 3

Support de la syntaxe avec < et > au lieu de min- et max- pour exprimer une fourchette de valeurs.
Exemple : 720 <= width < 1200

Colonne 4

Permet de définir une requête multimédia ciblant la résolution de l'appareil, en particulier en fonction des pixels de l'appareil utilisés par unité CSS.

Colonne 5

Supporte les media queries en fonction de la présence et de la précision de l'appareil de pointage de l'utilisateur, ainsi que de sa capacité à survoler les éléments de la page.

Remarques :

(1) Internet Explorer ne supporte pas les requêtes @media imbriquées.

(2) Internet Explorer et Opera mini ne supporte pas l'unité dpi dans les media queries.

1

Anciennes
requêtes media

2

Directive
@media

3

Syntaxe
'compris entre'

4

Test de la
resolution

5

Test des
interactions

Estimation de la prise en charge globale.

97%

96%

92%

94%

96%

Navigateurs sur ordinateurs :

Navigateurs sur mobiles :

Navigateurs obsolètes ou marginaux :

Internet Explorer

1

2

KaiOS Browser

Samsung Internet

Androïd Brower

Chrome pour Androïd

Baidu Browser

QQ Browser

Safari

Safari sur IOS

Chrome

Edge

Firefox

Opéra

Opéra Mobile

UC Browser pour Androïd

Firefox pour Androïd

Opéra mini

2

Voir le site Caniuse.com pour plus d'informations de compatibilité.

Caniuse

Caniuse

Caniuse

Caniuse

Caniuse