Lorsque vous utilisez le menu déroulant de notification de sujet (Watching/Tracking/Normal/Muted), le texte et l’icône de l’élément actuellement sélectionné deviennent invisibles en raison d’un contraste insuffisant entre la couleur d’arrière-plan de la sélection et les couleurs de premier plan.
Étapes pour reproduire
Ouvrez n’importe quel sujet
Cliquez sur le bouton de la cloche de notification en bas du sujet
Observez le niveau de notification actuellement sélectionné (par exemple, « Tracking »)
Comportement attendu
L’élément sélectionné doit avoir un texte et une icône clairement visibles avec un bon contraste.
Comportement actuel
Le libellé du texte disparaît ou devient très difficile à lire
L’icône de la cloche devient invisible
Le problème est le plus visible dans les thèmes sombres, mais peut affecter n’importe quel thème en fonction de la palette de couleurs
Détails techniques
Dans app/assets/stylesheets/common/select-kit/select-kit.scss, l’état .is-selected définit uniquement la couleur d’arrière-plan sans garantir le contraste du premier plan :
&.is-selected,
&.is-selected.is-highlighted {
background: var(--d-selected);
// Pas de remplacement de couleur pour le texte ou les icônes
}
La variable CSS --d-selected provient de la couleur $selected du thème, mais le texte (.name, .desc) et les icônes (.d-icon) conservent leurs couleurs par défaut, ce qui peut ne pas contraster correctement avec l’arrière-plan de la sélection.
Note : J'aurais ajouté l'autre image où l'icône disparaît pour l'état sélectionné, mais je suis nouveau et ne peux ajouter qu'une seule image pour le moment.
Ceci est une restriction pour les nouveaux utilisateurs. Vous pouvez parcourir certains sujets existants afin que votre niveau de confiance puisse rapidement atteindre 1.
Il semble que votre palette de couleurs n’ait pas été mise à jour depuis un certain temps, car ce n’est pas la couleur de sélection normale. Quand avez-vous mis à jour votre forum pour la dernière fois ?
Oui, c’est probablement le cas — j’ai vu des situations comme celle-ci où une palette de couleurs personnalisée créée avant l’ajout de nouvelles couleurs finit par avoir un mauvais contraste… @BrettH si vous créez une nouvelle palette de couleurs et l’utilisez, le problème persiste-t-il ?
Merci à tous pour vos suggestions. Permettez-moi de répondre aux questions :
NateDhaliwal - Je n’ai pas encore testé en mode sans échec, mais d’après ce que chapoi et Kris décrivent, je soupçonne que le mode sans échec résoudrait le problème car il reviendrait à la palette Lumière par défaut plutôt qu’à ma palette personnalisée.
@chapoi - Bonne question. Notre palette de couleurs a été créée il y a un certain temps - certainement avant que les couleurs selected et hover ne soient ajoutées à la palette de base. Je crois que la palette a été configurée lors du lancement de la communauté, et nous ne l’avons pas mise à jour depuis.
@awesomerobot - Cela a du sens. En regardant le code, je peux voir que resolved_colors calcule des valeurs de repli pour hover et selected en utilisant dark_light_diff si elles sont manquantes dans la palette. Mais le problème est que les couleurs de texte (.name, .desc, .d-icon) utilisent toujours leurs valeurs par défaut, qui ont été conçues pour la couleur de sélection de la palette Lumière par défaut - et non pour la valeur de repli calculée pour mon thème plus sombre.
Je vais créer une nouvelle palette et définir explicitement les couleurs selected et hover sur des valeurs qui contrastent correctement. Je soupçonne que cela résoudra le problème.
Une réflexion pendant que je teste : serait-il logique que le calcul de repli prenne également en compte le contraste du texte ? De cette façon, les anciennes palettes géreraient gracieusement les nouvelles additions de couleurs sans intervention manuelle. Juste une idée - je sais que les systèmes de couleurs sont difficiles à bien régler, et l’approche actuelle couvre probablement la plupart des cas. Je serais ravi de déposer une demande de fonctionnalité séparée si cela peut être utile.
