Nos amis graphistes pensent parfois qu'avoir des listes déroulantes (et donc leurs options) aux couleurs de votre charte graphique est un jeu d'enfant, or en 2016 il est encore difficile de plier l'affichage des éléments de formulaires, qu'il s'agisse de checkbox, select ou encore de boutons radio.

Des propriétés CSS telles que "appearance" font tranquillement leur chemin mais leur support par les navigateurs et très faible et laissent peu de place à la personnalisation. Prenons comme exemple ce que l'on peut faire en CSS3 : http://cssdeck.com/labs/styling-select-box-with-css3, l'utilisation de propriétés préfixées par le navigateur montre bien que nous sommes en cours de standardisation.

Il ne reste plus qu'à trouver un plugin JavaScript qui fasse le boulot, l'avantage étant que cela permet d'amener d'autres fonctionnalités à un select : recherche, tagging, chargement des options en ajax, templating des options.

Voici donc pour vous y retrouver les principales bibliothèques mises côte à côte selon des critères pouvant vous aider dans votre choix :

• navigation au clavier : donne une bonne indication de la qualité de l'intégration
• accessibilité : et comme navigation au clavier ne veut pas dire accessible, ce critère précise la présence d'attributs ARIA
• facilité de theming : ceci précise si le design utilise un préprocesseur spécifique (LESS/SASS) ou la difficulté à écrire du CSS pour le plugin
• thèmes : si le widget fournit une intégration de base avec différents frameworks CSS
• templating des options : il peut souvent être utile d'avoir des options dont le HTML est différent
• ajax : si la liste d'options peut être chargée par une requête asynchrone
• recherche : si une fonctionnalité de recherche est présente dans le champ
• tagging : si une fonctionnalité de création d'option à la volée est présente dans le champ
• taille minifiée : si la performance réseau est votre critère
• activité : précise l'activité de maintenance du plugin sur Github
• i18n/RTL : support des diacritiques et de la lecture de droite à gauche
• programmation : facilité de travailler avec et étendue des options et API du plugin
• fallback mobile : si le plugin ne remplace *pas* la sélection native en mobile, souvent plus pratique
• responsive : si le plugin n'est pas trop fixe en CSS et permet de s'adapter à la taille de son conteneur
• tests : la présence de tests est souvent gage de qualité
• npm/bower : si le plugin s'expose à la communauté

Je vous conseille de bien prendre en compte tous les critères, car si par exemple select2 est le plugin qui sort du lot, il est aussi le plus lourd, il sera donc approprié en cas d'utilisation poussée, mais si vous souhaitez uniquement charter vos select sur Bootstrap3 en restant accessible, je vous conseillerais Bootstrap-Select.