Media queries CSS

Le langage CSS (« Cascading Style Sheets », en français « feuilles de style en cascade ») constitue avec HTML et Ja­vaS­cript le socle de base pour concevoir des sites Web modernes. CSS est un langage de pro­gram­ma­tion, mais il ne décrit pas les dif­fé­rentes étapes de la ré­so­lu­tion d’un problème. Au lieu de cela, c’est un objectif à atteindre qui est défini. C’est pourquoi on dit que CSS est un langage dé­cla­ra­tif, à l’instar de SQL.

Les « media queries », ou requêtes média, qui servent à in­ter­ro­ger un pé­ri­phé­rique de sortie pour en connaître les pro­prié­tés, font partie des CSS. Elles sont utilisées en res­pon­sive web design pour adapter l’apparence du contenu. Mais comment fonc­tion­nent-elles exac­te­ment ?

Les media queries CSS ont été in­tro­duites avec la spé­ci­fi­ca­tion CSS3. Une requête média lie l’at­tri­bu­tion des pro­prié­tés CSS d’un élément à une ou plusieurs con­di­tions de support/média. Dans le cas le plus basique, on distingue le support sur lequel l’in­for­ma­tion est présentée, qui peut être un écran, une page imprimée (inclut l’im­pres­sion au format PDF) ou du texte lu à voix haute :

Une requête média CSS est spécifiée dans un bloc de code CSS à l’aide d’une règle '@media' spéciale. Les sé­lec­teurs et règles CSS qu’il contient ne sont activés que dans la condition spécifiée. Par exemple, les éléments qui ne doivent pas être affichés au format page imprimée peuvent être masqués :

Outre le support utilisé, les requêtes média CSS peuvent être mises en œuvre pour connaître les pro­prié­tés exactes du support concerné. Les requêtes média CSS sont la prin­ci­pale fonction à avoir rendu possible le res­pon­sive web design.

Le res­pon­sive web design, ou design réactif, vise à adapter l’affichage d’un site Web au pé­ri­phé­rique de la manière la plus fluide qui soit. Les requêtes média servent à connaître dif­fé­rentes pro­prié­tés du pé­ri­phé­rique d’affichage, que l’on appelle media features. Il devient ainsi possible de définir des règles de style pour dif­fé­rentes tailles d’écran. Qui plus est, ces règles de style peuvent être op­ti­mi­sées lorsque l’appareil mobile est incliné.

Voici une vue d’ensemble des media features les plus cou­ram­ment utilisées ac­tuel­le­ment en res­pon­sive design :

Voyons quelques exemples. Imaginons le titre principal d’un site Web. HTML fournit l’élément 'h1' à cette fin. Pour commencer, nous dé­fi­nis­sons les règles de style pour l’élément h1 sans penser au pé­ri­phé­rique d’affichage :

Ensuite, nous dé­fi­nis­sons une media query pour demander la largeur de l’écran. Dans cette requête, nous indiquons les règles de style à appliquer au titre à partir de cette largeur. Dans notre exemple, nous agran­dis­sons la taille de la police du titre h1 sur les écrans mesurant au moins 1024 pixels de large :

Nous ne modifions ici que la propriété 'font-size' du titre h1. L’in­ter­ligne est défini par la propriété 'line-height' comme valeur relative et est hérité (car il n’est pas ex­pli­ci­te­ment modifié). Dans notre exemple, l’in­ter­ligne de l’élément h1 est par défaut de 24px * 1,25 = 30px. Sur les écrans de 1024 pixels de large ou plus, l’in­ter­ligne augmente en pro­por­tion et devient 36px * 1,25 = 45px.

Ce mélange de règles de style exis­tantes et nou­vel­le­ment définies se retrouve dans le mot « cascade » de CSS : un élément hérite des règles de style des éléments parents ou règles générales déjà définies. Ha­bi­tuel­le­ment, on définit les pro­prié­tés de base des éléments, puis on écrase sé­lec­ti­ve­ment des pro­prié­tés dans certaines con­di­tions.

Autre exemple : imaginons que nous voulions afficher trois éléments dans un conteneur. Les éléments doivent être affichés les uns au-dessous des autres sur l’écran quand l’appareil est tenu à la verticale. Quand l’appareil bascule en mode paysage, la mise en page doit changer afin que les éléments ap­pa­rais­sent côte à côte. Grâce au module de mise en page Flexbox et à une requête média CSS demandant l’orien­ta­tion de l’appareil, cela peut être réalisé en quelques lignes de HTML et CSS. Pour cela, nous dé­fi­nis­sons d’abord le conteneur et les éléments contenus en HTML :

Nous dé­fi­nis­sons aussi les règles CSS suivantes. Nous at­tri­buons la propriété 'display: flex' au conteneur et dé­fi­nis­sons de manière con­di­tion­nelle la propriété 'flex-di­rec­tion' de celui-ci via une requête média CSS. Lorsque l’appareil sera tenu en mode paysage, les éléments s’af­fi­che­ront en ligne les uns à côté des autres ; lorsqu’il sera tenu en mode portrait, les éléments seront alignés les uns au-dessous des autres :

Outre les di­men­sions de l’écran et l’orien­ta­tion de l’appareil, on peut également demander la ré­so­lu­tion physique de l’écran au moyen d’une media query. C’est par­ti­cu­liè­re­ment in­té­res­sant pour l’affichage d’images en pixels. Imaginons qu’un logo soit dis­po­nible en deux versions, chacune optimisée pour les écrans à basse et haute ré­so­lu­tion. Une technique simple pour afficher le logo qui convient dans chaque cas consiste à placer les deux versions sur le site. À l’aide d’une media query CSS, nous demandons la ré­so­lu­tion de l’écran et nous masquons la version qui n’est pas né­ces­saire à l’aide de 'display: none'. Cette méthode pourrait res­sem­bler à ceci en code HTML et CSS :

Dans nos ex­pli­ca­tions pré­cé­dentes, nous avons parlé « d’écran » en relation avec la largeur dis­po­nible du pé­ri­phé­rique de sortie. C’est vrai d’un point de vue con­cep­tuel, mais tech­ni­que­ment ce n’est pas tout à fait exact. Le na­vi­ga­teur fonc­tionne en interne avec le concept de « viewport ». Pour que la largeur du viewport cor­res­ponde réel­le­ment à la largeur de l’écran, une dé­cla­ra­tion 'meta-viewport' est né­ces­saire dans la balise '<head>' du document HTML. Sans celle-ci, la page s’affichera sur les appareils mobiles comme sur un poste fixe, à la simple dif­fé­rence que sa taille globale sera con­si­dé­ra­ble­ment réduite.

En res­pon­sive web design, les éléments doivent s’adapter à la taille de l’écran. Il s’agit souvent de définir les di­men­sions des éléments dans dif­fé­rentes con­di­tions. La spé­ci­fi­ca­tion CSS prévoit une multitude d’unités, l’unité de dimension la plus simple étant pro­ba­ble­ment le pixel. Par exemple, une image de 1080 pixels a des di­men­sions de 1920 pixels de large sur 1080 pixels de haut.

Le pixel est une entité absolue, et par dé­fi­ni­tion ne s’adapte pas à l’espace dis­po­nible. Prenons un exemple qui montre pourquoi cela peut être pro­blé­ma­tique. Supposons qu’une page Web contienne une image d’une largeur de 1920 pixels. Si nous dé­fi­nis­sons la largeur de l’image à cette valeur par CSS, l’affichage risque d’être perturbé sur les petits écrans, puisque l’image sortira de l’espace dis­po­nible.

Nous dé­fi­nis­sons ici une image en HTML à l’aide de la balise '<img>' :

Dans la feuille CSS, nous fixons la largeur à 1920 pixels :

Dans ce scénario, il serait mieux d’utiliser une unité relative plutôt que des pixels. Depuis ses premiers jours, CSS connaît le pour­cen­tage comme unité relative. Si nous dé­fi­nis­sons la largeur de l’image à « 100 % » via CSS, l’image s’adaptera de manière fluide à l’espace dis­po­nible. Cela fonc­tionne parce que les pour­cen­tages se rap­por­tent toujours à l’élément englobant.

Nous avons fait un grand pas vers notre objectif d’adapter la largeur d’une image à l’espace dis­po­nible. Cependant, nous avons créé un nouveau problème : sur un écran de plus de 1920 pixels, l’image sera agrandie et donc pixel­li­sée. Par con­sé­quent, nous devons également limiter la largeur maximale de l’image à ses di­men­sions réelles en pixels :

CSS reconnaît un certain nombre d’autres unités, en plus du pixel et du pour­cen­tage. Les unités relatives em, rem et vw, vh offrent toutes des uti­li­sa­tions in­té­res­santes en res­pon­sive design. Voici un aperçu des unités CSS les plus cou­ram­ment utilisées pour obtenir un design adaptatif :

Outre les requêtes média basiques pré­sen­tées jusqu’ici, il est aussi possible d’écrire des media queries CSS complexes. CSS fournit à cette fin les opé­ra­teurs logiques 'and', 'or', et 'not'. Voici un exemple de requête complexe :

En plus des media features déjà exis­tantes, qui peuvent être in­ter­ro­gées au moyen des media queries, d’autres fonctions in­té­res­santes sont prévues à l’avenir. La spé­ci­fi­ca­tion « CSS Media Queries Level 5 » (CSS5) prévoit les nouvelles options d’in­ter­ro­ga­tion suivantes :

Une autre nouveauté attendue avec la parution de CSS5 est les container queries. Grâce à elles, il sera permis pour la première fois de lier les règles de style des éléments aux pro­prié­tés du conteneur qui les entoure. Les container queries con­tras­tent donc avec les media queries CSS, qui in­ter­ro­gent les pro­prié­tés globales du pé­ri­phé­rique d’affichage. La mise en œuvre des container queries permettra de gérer les cas par­ti­cu­liers pour lesquels on recourait jusqu’à présent à Ja­vaS­cript ou à des media queries complexes.

Dans le contexte du res­pon­sive web design et des media queries CSS, le terme « break­point » (point de rupture) revient souvent. Un break­point est en fait une largeur d’écran définie pour laquelle un ensemble de règles CSS dé­ter­mi­nées à l’aide de media queries est activé. On peut vi­sua­li­ser les break­points définis sur un site Web en ouvrant les outils de dé­ve­lop­pe­ment dans le na­vi­ga­teur. Si l’affichage adaptatif est actif, les break­points ap­pa­rais­sent sous forme de barres colorées au-dessus de la page Web.

Une bonne pratique reconnue pour concevoir des sites web adap­ta­tifs est l’approche mobile first. Quand un site Web est développé suivant cette approche, le style est pensé en premier lieu pour les petits écrans. Ces spé­ci­fi­ca­tions de style cons­ti­tuent le socle de base du design. Sur cette base, plusieurs break­points sont définis pour des écrans de plus en plus grands. Au sein des break­points, de nouvelles règles de style sont définies de manière sélective pour les éléments et rem­pla­cent les règles exis­tantes pour les écrans plus petits.

L’approche mobile first est bien illustrée par le célèbre utility framework CSS appelé « Tachyons ». Celui-ci définit trois break­points par défaut : 'not-small', 'medium' et 'large’ :

Notez que dans l’approche mobile first, il n’y a pas de break­point 'small'. Les spé­ci­fi­ca­tions pour les petits appareils sont sim­ple­ment définies sans break­point.

Au sein des break­points, des règles de style sont définies pour les éléments dont l’affichage doit être adapté à des écrans de dif­fé­rentes tailles. Vous comprenez peut-être déjà que cette cen­tra­li­sa­tion de la codebase CSS d’un projet Web pose problème. Nor­ma­le­ment, il est pré­fé­rable de ras­sem­bler toutes les pro­prié­tés CSS d’un élément dans un fichier séparé.

Pour mo­du­la­ri­ser le code CSS d’un projet, dif­fé­rents pré­pro­ces­seurs CSS ont d’abord été utilisés. Vous con­nais­sez peut-être les langages Sass, Less ou Stylus. Par la suite, un post-pro­ces­seur CSS est venu s’ajouter avec le projet Node.js PostCSS. Toutes les tech­no­lo­gies sus­men­tion­nées per­met­tent d’en­cap­su­ler les media queries CSS sous un sélecteur CSS. De cette manière, les règles de style d’un élément peuvent être définies col­lec­ti­ve­ment pour toutes les con­di­tions de média. Voici un exemple avec Stylus.

Fichier Stylus 'text.styl' pour les pro­prié­tés du texte :

Fichier Stylus 'link.styl' pour les pro­prié­tés des liens :

Le pré­pro­ces­seur Stylus traduit les fichiers en CSS et regroupe les règles des media queries CSS insérées sous un seul break­point. Le code Stylus présenté se traduit par le code CSS suivant :

La méthode con­sis­tant à en­cap­su­ler les requêtes média CSS dans les règles de style d’un élément et à les traiter à l’aide du pro­ces­seur CSS fonc­tionne. Néanmoins, elle oblige toujours le dé­ve­lop­peur à faire des allers-retours entre les niveaux HTML et CSS. Il est également né­ces­saire d’attribuer des noms de classe uniques aux éléments en HTML. Tout cela entraîne une com­plexité in­dé­si­rable. C’est là qu’in­ter­vien­nent les utility fra­me­works CSS, une tech­no­lo­gie reconnue de nos jours.

Un utility framework associe des pro­prié­tés CSS atomiques à des break­points. Les classes CSS qui en résultent peuvent être at­tri­buées à n’importe quel élément du code HTML. Il devient alors possible de définir des mises en page et des com­po­sants adap­ta­tifs uni­que­ment en HTML, sans avoir à écrire de code CSS. L’uti­li­sa­tion d’un utility framework CSS permet un pro­to­ty­page rapide et convient idéa­le­ment au dé­ve­lop­pe­ment de com­po­sants. Pour cette raison, les utility fra­me­works CSS sont souvent employés en relation avec des tech­no­lo­gies orientées com­po­sants, telles que React et Vue.

Voyons un autre exemple, emprunté au framework Tachyons. Jetez un œil au code CSS ci-dessous. Nous dé­fi­nis­sons d’abord les classes 'mw1' à 'mw3', qui limitent la largeur maximale de tout élément à des valeurs comprises entre '1rem' et '3rem'. Ensuite, nous dé­fi­nis­sons des classes CSS cor­res­pon­dantes dans les break­points 'medium' et 'large', qui incluent l’abré­via­tion du break­point concerné dans leur nom :

Grâce à ces classes CSS, nous pouvons écrire des éléments adap­ta­tifs en­tiè­re­ment en HTML. L’extrait de code HTML suivant définit une image dont la largeur maximale est de '1rem' sur les petits écrans. L’image s’adapte au­to­ma­ti­que­ment à la largeur d’écran dis­po­nible. Sur les écrans de taille moyenne, l’élément occupera au maximum '2rem', sur les grands écrans '3rem'.

Les « utility fra­me­works » CSS sont un vaste ensemble de classes atomiques dont chacune détermine une seule propriété CSS. En plus des di­men­sions d’un élément, cela inclut des in­for­ma­tions sur la ty­po­gra­phie, les couleurs et à peu près n’importe quelle autre ca­rac­té­ris­tique ima­gi­nable. Pour chaque propriété atomique, un « utility framework » contient des classes pour chaque break­point défini. En combinant plusieurs classes, il est possible d’assembler un nombre presque infini d’éléments en­tiè­re­ment adap­ta­tifs.

Le framework Tachyons évoqué plus haut a déjà plusieurs années et n’est plus entretenu. Toutefois, en raison de sa relative sim­pli­cité, Tachyons mérite d’être considéré pour apprendre le res­pon­sive web design. Le moyen le plus facile de com­prendre cette méthode est de regarder les com­po­sants Tachyons. Il s’agit d’éléments il­lus­tra­tifs qui sont en­tiè­re­ment définis à l’aide de classes utility.

Une version moderne existe aujourd’hui avec Tail­windCSS, qui peut être considéré comme le suc­ces­seur spirituel de Tachyons. Tail­windCSS comporte certains avantages par rapport à Tachyons. Ainsi, le projet est toujours ac­ti­ve­ment développé et prend en charge d’emblée de nombreux systèmes po­pu­laires de dé­ve­lop­pe­ment front-end. Qui plus est, Tail­windCSS peut être en­tiè­re­ment per­son­na­lisé en fonction des besoins spé­ci­fiques de votre projet. Tous les pré­ré­glages, tels que les break­points, l’échelle de la taille de police, etc. sont fa­ci­le­ment con­fi­gu­rables.

Si les utility fra­me­works CSS sont pratiques à utiliser, ils pré­sen­tent néanmoins un in­con­vé­nient majeur : il faut parfois une grande quantité de classes atomiques pour définir un élément. En outre, par défaut, le fichier texte source CSS contient des classes pour l’ensemble des com­bi­nai­sons de valeurs de pro­prié­tés CSS et de break­points. Dans le cas de Tail­windCSS, les classes se comptent en milliers, si bien que le fichier CSS non compressé pèse plusieurs mé­gaoc­tets, une situation intenable du point de vue des per­for­mances.

Heu­reu­se­ment, Tail­windCSS y remédie de deux manières. D’une part, le framework connaît l’ins­truc­tion '@apply', qui sert à grouper des com­bi­nai­sons de classes utility utilisées plusieurs fois sous un nouveau nom de classe. D’autre part, Tail­windCSS prend en charge l’uti­li­taire PurgeCSS. Celui-ci est employé dans le cadre du processus de build pour supprimer toutes les classes utility inu­ti­li­sées du build de pro­duc­tion. PurgeCSS traite les modèles HTML du projet et n’inclut que les classes CSS trouvées dans le fichier source CSS généré. Cela permet de réduire le fichier source à une taille ac­cep­table.