Tous les articles

Innovation

Les nouveautés CSS à suivre ou à utiliser dès maintenant

Etienne Moureton

·4 min

Le CSS devient avec le temps de plus en plus fonctionnel, là où on le trouvait trop déclaratif par le passé. De nombreuses features, ayant fait des préprocesseurs SCSS ce qu’ils sont aujourd’hui, arrivent ou sont déjà arrivées en CSS natif. Même si le support par les navigateurs prend souvent un peu de temps, la migration en vaut le coup en terme de DX (Developer Experience). Prenons l’exemple des variables SCSS qui ne sont pas accessibles lors du runtime, là où les variables CSS arrivées après le sont.

Nous allons voir quelles sont les nouveautés CSS les plus attendues chez unflux et en quoi elles vont améliorer l’accessibilité, la DX ou les performances de vos services numériques.

À quel moment adopter les nouveautés CSS ?

Chez unflux, la règle est assez simple. En se basant sur https://caniuse.com/, on s’assure que la fonction souhaitée est supportée a minima à 95% (et sans préfixe). Une valeur qui permet de couvrir un large panel d’utilisateurs, sachant que la plupart des laissés pour compte sont de (très) vieux navigateurs. Safari, Chrome (et ses dérivés), Firefox et autres sont toujours présents dans les 95%.

1. Container Queries

Principe

Commençons avec un aspect lié au responsive. Que l’on construise des layouts avec les flexbox, les grid ou n’importe quoi d’autre, il est très rare de ne pas avoir recours au Media Queries. Ces petites déclarations permettent d’appliquer des styles spécifiques en fonction de la taille du viewport, soit ce qui est visible à l’écran. C’est sympa pour gérer globalement un layout, mais peut vite se révéler être un casse-tête pour des petites parties d’un design.

Les Container Queries, c’est le Messie. Au lieu de baser le resize d’un élément sur la taille du viewport, on va prendre la taille de son parent. Cela va particulièrement être utile pour les applications très dynamiques, où le layout peut très rapidement changer, sans forcément changer la taille de l’écran.

Exemple

En prenant l’exemple d’une grille de produits à côté de laquelle se trouve une sidebar avec des filtres que l’on peut étendre ou cacher. La largeur de la grille va donc dépendre de si la sidebar est présente ou non, les container queries vont permettre de se baser justement sur la largeur de la grille pour, par exemple, afficher les images de tailles différentes.

Support

Actuellement, 76,93% des appareils supportent la fonctionnalité. Trop peu pour être utilisée en production mais assez pour pouvoir être testée et commencer à se familiariser avec le principe.

Différence entre Media Queries et Container Queries

2. Les préfixes :is, :has et :where

Principe

Cette fois, on ne va pas parler d’une propriété mais d’une nouveauté (même plusieurs) au niveau des sélecteurs. :has facilite le ciblage d’éléments en fonction de ses enfants, quelque chose de presque impossible jusqu’ici, même avec des préprocesseurs, il fallait souvent passer par du JS. :is va quant à lui faciliter l’écriture du CSS, il n’apporte pas forcément de possibilités supplémentaires, mais limite le nombre de lignes écrites.

Exemple

  • :has : Si on souhaite appliquer un style différent à un élément .card en fonction de s’il possède une image ou non, on va faire un .card:has(img).
  • :is : Au lieu d’écrire .card .content h1, .card .content .title, .card .content .paragraph si on souhaite leur appliquer le même style, on va plutôt faire .card .content > *:is(h1, .title, .paragraph)

Support

Malheureusement, aucun des trois sélecteurs n’est encore suffisamment supporté. :is, :has et :where sont respectivement à 93.06% (97 sans préfixe), 81.7% et 90.44%.

Exemple d’utilisation de :has

Exemple d’utilisation de :has

3. De nouvelles unités de mesure

Principe

On s’attaque cette fois-ci aux unités de mesure. Les nouvelles arrivantes vont grandement nous faciliter la vie en améliorant la DX et indirectement les performances. Voici une liste des plus importantes à nos yeux :

  • dvh/dvw : hauteur/largeur actuelle du viewport, excluant l’interface du navigateur
  • svmin : sélectionne la plus petite valeur entre svw et swh

Exemple

Aujourd’hui, en utilisant 100vh, on prend en compte l’interface de l’utilisateur. Sur mobile, on se retrouve avec un scroll forcé puisque la barre de recherche (notamment sur iOS) est prise en compte. En utilisant dvh, on ne va avoir que la partie visible par l’utilisateur. Cela rend le développement plus simple et évite de devoir passer par du JS pour calculer un “realViewport” qui vient rajouter de la logique là où ce n’est pas nécessaire (et donc une potentielle perte de performances).

Avec le svmin, il va être de plus en plus simple de créer des éléments carrés. On va pouvoir utiliser cette unité en hauteur et en largeur, elle sera toujours la même contrairement aux pourcentages, vh ou vw.

Différence entre vh et dvh

En clair

Plein de belles nouveautés ultra prometteuses que nous avons testées et approuvées chez unflux. Il ne reste plus qu’elles soient supportées par 95% des navigateurs pour être utilisées à plus grande échelle. Et si vous avez envie d’avoir de l’avance sur votre temps, pourquoi ne pas les intégrer dès maintenant dans votre prochain projet web ?

Agenda de Nicolas