color-mix() pour dériver la couleur de survol d’un bouton d’administration

background-color: color-mix(in srgb, var(--extension-couleur-marque) 85%, black); — cette seule ligne remplace ce qui, il y a encore peu, nécessitait trois couleurs codées en dur ou un préprocesseur Sass pour générer les états hover et actif d’un bouton. Pour une extension qui propose un réglage de couleur de marque dans son écran d’administration, c’est un vrai gain.

Le scénario est classique : une extension de gestion de rendez-vous laisse l’utilisateur choisir une couleur d’accent via un sélecteur natif, et cette couleur doit se propager aux boutons, aux badges de statut et à leurs états interactifs. Sans color-mix(), il fallait soit imposer une palette fixe, soit calculer les teintes dérivées côté PHP avant de les injecter en CSS inline.

Le problème avec les couleurs codées en dur

Quand la couleur de marque est fixe, coder trois nuances (normale, hover, active) est simple. Le problème apparaît dès que cette couleur devient un réglage utilisateur, stocké par exemple via register_setting(). Il faut alors soit recalculer les variantes en PHP à chaque affichage, avec une fonction de manipulation de teinte HSL maison, soit accepter que le hover reste identique à l’état normal, ce qui dégrade l’expérience.

La première solution fonctionne, mais alourdit le code : il faut convertir l’hexadécimal en HSL, assombrir ou éclaircir la luminosité, reconvertir en hexadécimal, puis injecter le résultat dans une balise <style> générée dynamiquement. C’est fragile et difficile à maintenir sur la durée.

Ce que color-mix() change concrètement

color-mix() est une fonction CSS native qui mélange deux couleurs selon un ratio donné, directement dans le navigateur. Elle prend en charge plusieurs espaces colorimétriques, dont srgb et oklch, ce dernier donnant des résultats perceptuellement plus réguliers pour les couleurs claires et sombres.

:root {
    --extension-couleur-marque: #2a6df4;
}

.rdv-bouton {
    background-color: var(--extension-couleur-marque);
    border: none;
    color: #fff;
    padding: 0.6em 1.2em;
}

.rdv-bouton:hover {
    background-color: color-mix(in srgb, var(--extension-couleur-marque) 85%, black);
}

.rdv-bouton:active {
    background-color: color-mix(in srgb, var(--extension-couleur-marque) 70%, black);
}

.rdv-badge-attenue {
    background-color: color-mix(in srgb, var(--extension-couleur-marque) 20%, white);
    color: color-mix(in srgb, var(--extension-couleur-marque) 60%, black);
}

Toute la logique de dérivation reste côté navigateur. PHP se contente d’écrire la variable --extension-couleur-marque une seule fois, par exemple via wp_add_inline_style(), sans jamais calculer de teinte dérivée lui-même.

Injecter proprement la couleur choisie par l’utilisateur

Le réglage stocké doit rester une simple couleur hexadécimale validée côté serveur, et la génération de la feuille de style se limite à écrire cette variable.

function rdv_injecter_couleur_marque() {
    $couleur = get_option( 'rdv_couleur_marque', '#2a6df4' );
    $css = sprintf( ':root { --extension-couleur-marque: %s; }', sanitize_hex_color( $couleur ) );
    wp_add_inline_style( 'rdv-admin-styles', $css );
}
add_action( 'admin_enqueue_scripts', 'rdv_injecter_couleur_marque' );

sanitize_hex_color() garantit qu’aucune valeur arbitraire ne se retrouve injectée telle quelle dans la feuille de style, ce qui reste une précaution nécessaire même pour un réglage réservé aux administrateurs.

Limites à connaître avant d’en faire une dépendance forte

La prise en charge de color-mix() est large dans les navigateurs modernes, mais un écran d’administration destiné à des postes anciens ou verrouillés en entreprise mérite un filet de sécurité. La solution la plus robuste consiste à définir une couleur de repli statique juste avant la règle utilisant color-mix() ; les navigateurs qui ne comprennent pas la fonction ignorent simplement la déclaration invalide et conservent la valeur précédente.

• Toujours déclarer une couleur de repli avant la déclaration utilisant color-mix().
• Préférer l’espace oklch quand la marque propose plusieurs teintes très contrastées, pour un résultat visuellement plus cohérent.
• Ne jamais laisser une valeur de réglage utilisateur atteindre le CSS sans passer par sanitize_hex_color() ou une validation équivalente.

Sur nos projets, ce changement a fait disparaître une bonne dizaine de lignes de calcul de teinte en PHP par extension, sans aucune perte de flexibilité pour l’utilisateur final.

En résumé

color-mix() déplace un calcul auparavant fait côté serveur, en PHP, vers le navigateur, là où il est finalement le plus naturel de le faire : au moment du rendu. Pour toute extension qui expose un réglage de couleur, c’est une simplification directe, qui évite d’écrire et de maintenir sa propre fonction de manipulation de teinte HSL.