/ Articles
La malédiction des select enfin levée ? 👨🎨
Tout développeur frontend connaît comme sa poche le <select> pour créer un menu déroulant 👇
Au grand dam des développeurs, ce <select> était pourtant jusqu'à présent très peu personnalisable.
Impossible, par exemple, de changer directement la flèche à droite du selecteur ou l'apparence des options du menu déroulant sans des stratégies de contournement qui donnaient l'impression de travailler contre la plateforme web plutôt qu'avec elle.
On se retrouve alors coincé avec un rendu visuel dicté par le navigateur et le système d'exploitation de l'utilisateur soit une apparence variabe d'un client à un autre. Pas l'idéal pour un site ou une application qui cherche à maintenir une cohérence visuelle et une expérience unique pour tous ses visiteurs...
La tentation est alors forte de recréer soi-même un <select> en bricolant à l'aide de <div> ou de <button> ou de se tourner vers des librairies de composants exploitant cette voie pour nous donner la main complète sur son apparence.
Jetons un œil par exemple au select de la librairie Shadcn UI, l'une des bibliothèques de composants les plus populaires 👇
Même fonctionnement, même apparence. On croirait un vrai ! 🪞
À la lecture du code source, on réalise toutefois qu'il ne s'agit pas d'un <select> mais d'un <button> augmenté d'une ribambelle d'attributs et qui requiert d'importer une librairie Javascript (ici @radix-ui/react-select) pour pouvoir fonctionner comme un <select> natif.
Pourquoi est-ce un problème Jamy ? D'abord parce qu'en s'en remettant à l'API d'un composant externe, on perd le bénéfice d'une implémentation native et performante du composant <select> optimisée pour le navigateur. Il faut également blinder ces balises de remplacement avec toute une série d'attributs pour satisfaire les standards d'accessibilité. Ensuite parce que cela nous contraint à ajouter une dépendance à notre projet pour émuler un comportement déjà existant à la seule fin de contourner des limitations stylistiques...
Allons bon, quitte à utiliser des <button> et des <div> pour contrefaire notre <select>, pourquoi ne pas tenter une implémentation personnelle afin de ne pas se reposer sur une librairie externe pour un composant aussi essentiel ?
Parce que rien n'est moins simple ! Beaucoup de difficultés surgissent dans cette quête en raison des nombreux aspects fonctionnels que doit couvrir un menu déroulant correct prétendant au titre de <select> :
- Navigation au clavier et gestion du focus, notamment pour l'accessibilité ;
- Adaptation mobile ;
- Détection du clic à l'extérieur pour la fermeture ;
- Repositionnement automatique selon la bordure de fenêtre la plus proche ;
- Chevauchement possible avec d'autres éléments notamment lors du scroll
😮💨
Chrome notre sauveur (again)
Mais voilà que depuis peu avec Chrome, on peut enfin styliser un <select> jusque dans ses moindres détails tout en profitant de ses fonctionnalités natives !
La première étape consiste à désactiver le style par défaut du <select> choisi par votre navigateur en optant pour la nouvelle propriété appearance: base-select.
On obtient alors un <select> minimaliste et désormais totalement personnalisable !
Certes rien de fou à première vue, celui-ci paraît même moins esthétique ainsi dépouillé de ses plus beaux atours. Mais croyez-moi, ce <select> offre de toutes nouvelles possibilités qui vont lui permettre un sacré glow up
Explorons-en quelques-unes !
Insérer des images ou des svg
Il est dorénavant possible d'insérer des éléments visuels (images, svg etc.) qui étaient auparavant ignorés par le parser du navigateur. Exemple avec ce sélecteur de frameworks Javascript 👇
Customiser l'élément sélectionné
Souvent l'élément sélectionné peut avoir des contraintes d'affichage qui diffèrent de celles de la liste d'options. La balise <selectedcontent> permet ainsi de cibler spécifiquement ce type d'élément lorsqu'il occupe cette place et de lui appliquer des styles personnalisés.