L’Outil Surpuissant pour Exploser ton Chiffre d'Affaires en 2024 !
Comment configurer les jeux de couleurs d'application avec les propriétés personnalisées CSS
Les variables sont un outil de base qui aide à organiser les couleurs sur un projet. Pendant longtemps, les ingénieurs frontaux ont utilisé des variables de préprocesseur pour configurer les couleurs d'un projet. Mais maintenant, de nombreux développeurs préfèrent le mécanisme natif moderne pour organiser les variables de couleur – c'est Propriétés personnalisées CSS . Leur avantage le plus important par rapport aux variables de préprocesseur est qu'elles fonctionnent en temps réel, pas au stade de la compilation du projet, et prennent en charge le modèle en cascade, qui vous permet d'utiliser l'héritage et la redéfinition des valeurs à la volée.
Lorsque vous essayez d'organiser un jeu de couleurs d'application, vous pouvez toujours placer toutes les propriétés personnalisées liées à la couleur dans la section racine, les nommer et les utiliser à tous les endroits nécessaires.
See the Pen [Custom Properties for Colors] (https : //codepen.io/smashingmag/pen/RwaNqxW) par Artur Basak .
Ci-dessous, je veux suggérer une approche plus flexible et plus résistante sur la façon de diviser les variables de couleur à l'aide de propriétés personnalisées, ce qui peut résoudre bon nombre de ces problèmes. [19659011] Configuration de la palette de couleurs
La coloration de n'importe quel site Web commence par la configuration d'un jeu de couleurs. Un tel schéma est basé sur la roue chromatique . Habituellement, seules quelques couleurs primaires forment la base d'une palette, les autres sont des couleurs dérivées – les tons et les tons moyens. Le plus souvent, la palette est statique et ne change pas pendant l'exécution de l'application Web.
Selon la théorie des couleurs il n'y a que quelques options pour les jeux de couleurs:
- Schéma monochromatique (un couleur primaire)
- Schéma complémentaire (deux couleurs primaires)
- Schéma triade (trois couleurs primaires)
- Schéma tétradique (quatre couleurs primaires)
- Motif adjacent (deux ou trois couleurs primaires)
- For my Par exemple, je vais générer un jeu de couleurs triade en utilisant le service Paletton :
Maintenant, j'ai trois couleurs principales, sur la base de celles-ci, je vais calculer les tons et les demi-tons, le format HSL en combinaison avec la fonction calc est un outil très utile pour cela. En modifiant la valeur de luminosité, je peux générer plusieurs couleurs supplémentaires pour la palette.
Voir le stylo [HSL Palette] (https://codepen.io/smashingmag/pen/OJNPaQW) par Artur Basak .
Maintenant si la palette est modifiée, alors il faudra changer uniquement la valeur des couleurs primaires, le le reste sera recalculé automatiquement.
Si vous préférez les formats HEX ou RVB, peu importe, une palette peut être formée au stade de la compilation du projet avec les fonctions correspondantes du préprocesseur – par exemple avec SCSS et [19659029] fonction de réglage des couleurs . Comme je l'ai déjà mentionné, cette couche est principalement statique, il peut être très rarement nécessaire de changer la palette dans une application en cours d'exécution, c'est pourquoi nous pouvons la calculer avec des préprocesseurs.
Je recommande également de générer à la fois un littéral HEX et RVB pour chaque couleur , cela permettra de jouer avec le canal alpha dans le futur.
Voir le Pen [SCSS Palette] (https://codepen.io/smashingmag/pen/oNxgQqv) par Artur Basak .
Le niveau de la palette est le seul niveau où la couleur est encodée directement dans les noms de variables, c'est-à-dire que nous pouvons identifier la couleur de manière unique par lecture du nom.
Définir le thème ou les couleurs fonctionnelles
Une fois la palette terminée, l'étape suivante est le niveau des couleurs fonctionnelles . À ce niveau, la valeur de la couleur n'est pas aussi importante que son objectif, la fonction qu'elle remplit – ce qu'elle colorise exactement. Par exemple, la couleur de la marque principale ou de l'application, la couleur de la bordure, la couleur du texte sur un fond sombre, la couleur du texte sur un fond clair, la couleur de l'arrière-plan du bouton, la couleur du lien, la couleur du lien de survol, la couleur du texte de l'indice, etc. [19659006] Ce sont des choses extrêmement courantes pour presque tous les sites Web ou applications. On peut dire que de telles couleurs sont responsables d'un certain thème de couleur de l'application. De plus, les valeurs de ces variables sont extraites strictement de la palette. Ainsi, nous pouvons facilement changer les thèmes d'application simplement en utilisant différentes palettes de couleurs.
Ci-dessous, j'ai créé trois contrôles d'interface utilisateur typiques: un bouton, un lien et un champ de saisie. Ils sont colorés à l'aide de variables fonctionnelles qui contiennent des valeurs de la palette que j'ai générée ci-dessus. La principale variable fonctionnelle responsable du thème de l'application (marque conditionnelle) est la variable de couleur primaire.
En utilisant les trois boutons en haut, vous pouvez changer de thème – changer la couleur de la marque pour les contrôles. Le changement s'effectue à l'aide de l'API CSSOM appropriée (setProperty) .
See the Pen [Functional Colors] (https://codepen.io/smashingmag/pen/poyvQLL) de Artur Basak .
Cette approche est pratique non seulement pour la thématisation, mais aussi pour la configuration de pages Web individuelles. Par exemple, sur le site Web zubry.by j'ai utilisé une feuille de style commune et une variable fonctionnelle - page-color pour coloriser le logo, les en-têtes, les commandes et sélection de texte pour toutes les pages. Et dans les propres styles de chaque page, je viens de redéfinir cette variable pour définir la page sa couleur primaire individuelle.
Utiliser les couleurs des composants
Les grands projets Web contiennent toujours une décomposition, nous divisons tout en petits composants et les réutilisons dans de nombreux endroits. Chaque composant a généralement son propre style, peu importe ce que nous avons utilisé pour décomposer les modules BEM ou CSS, ou une autre approche, il est important que chacun de ces éléments de code puisse être appelé portée locale et réutilisé.
En général, je voir le point d'utiliser des variables de couleur au niveau du composant dans deux cas.
Le premier est lorsque des composants qui, selon le guide de style de l'application, sont répétés avec des paramètres différents – par exemple, des boutons pour différents besoins comme primaire bouton (marque), bouton secondaire, tertiaire, etc.
Le second est lorsque des composants qui ont plusieurs états avec des couleurs différentes – par exemple, survol des boutons, états actifs et focus; états normal et invalide pour le champ d'entrée ou de sélection, etc.
Un cas plus rare où les variables de composant peuvent être utiles est la fonctionnalité d'une «étiquette blanche». La «marque blanche» est une fonction de service qui permet à l'utilisateur de personnaliser ou de personnaliser une partie de l'interface utilisateur pour améliorer l'expérience d'interaction avec ses clients. Par exemple, des documents électroniques qu'un utilisateur partage avec ses clients via un service ou des modèles de courrier électronique. Dans ce cas, les variables au niveau du composant aideront à configurer certains composants séparément du reste du thème de couleur de l'application.
Ci-dessous, j'ai ajouté à mon exemple des contrôles pour personnaliser les couleurs du bouton principal (marque). En utilisant les variables de couleur du niveau de composant, nous pouvons configurer les contrôles de l'interface utilisateur séparément les uns des autres.
Voir le stylo [Component Colors] (https://codepen.io/smashingmag/pen/LYNEXdw) par Artur Basak .
Comment déterminer le niveau d'une variable?
Je suis tombé sur la question de savoir comment comprendre peut être mis à la racine (thème ou niveau fonctionnel), et ce qu'il faut laisser au niveau d'un composant. C'est une excellente question à laquelle il est difficile de répondre sans voir la situation dans laquelle vous travaillez.
Malheureusement, la même approche que dans la programmation ne fonctionne pas avec les couleurs et les styles, si nous voyons 3 morceaux de code identiques alors nous devons
La couleur peut être répétée d'un composant à l'autre, mais cela ne veut pas dire que c'est une règle, il ne peut y avoir aucune relation entre ces composants. Par exemple, la bordure du champ de saisie et l'arrière-plan du bouton principal – oui, dans mon exemple ci-dessus c'est le cas, mais vérifions l'exemple suivant:
See the Pen [Color Split: Only Palette] (https://codepen.io / smashingmag / pen / YzqPRLX) de Artur Basak .
The dark grey la couleur est répétée – il s'agit de la bordure du champ de saisie, de la couleur de remplissage de l'icône de fermeture et de l'arrière-plan du bouton secondaire. Mais ces composants ne sont en aucun cas liés les uns aux autres. Si la couleur de la bordure du champ de saisie change, nous ne changerons pas l'arrière-plan du bouton secondaire. Pour un tel cas, nous devons garder ici juste la variable de la palette.
Et le vert? Nous pouvons clairement le définir comme la couleur principale ou de la marque, très probablement, si la couleur du bouton principal change, alors la couleur du lien et de l'en-tête du premier niveau changera également.
Qu'en est-il du rouge? L'état non valide des champs de saisie, des messages d'erreur et des boutons destructifs aura la même couleur à tout le niveau de l'application. Ceci est un modèle. Maintenant, je peux définir plusieurs variables fonctionnelles communes dans la section racine:
See the Pen [Color Split: Functional Level] (https://codepen.io/smashingmag/pen/MWyYzGX) by Artur Basak .
En ce qui concerne le niveau de couleurs des composants, nous pouvons facilement identifier les composants qui peuvent être personnalisés à l'aide de propriétés personnalisées.
Le bouton est répété avec différents paramètres, la couleur d'arrière-plan et le texte pour différents cas d'utilisation changent – cas primaire, secondaire, tertiaire, destructif ou négatif.
Le champ de saisie a deux états – incorrect et normal, où les couleurs d'arrière-plan et de bordure différer. Et donc, mettons ces paramètres dans des variables de couleur au niveau des composants correspondants.
Pour le reste des composants, il n'est pas nécessaire de définir des variables de couleur locales, cela sera redondant.
See the Pen [Color Split: Component Level] (https://codepen.io/smashingmag/pen/BaKyGVR) par Artur Basak .
Vous devez vous plonger dans le langage des modèles de votre projet, qui est probablement en cours de développement par l'équipe de conception et UX. Les ingénieurs doivent bien comprendre tout le concept de langage visuel, ce n'est qu'alors que nous pouvons déterminer ce qui est commun et devrait vivre au niveau fonctionnel, et ce qui doit rester dans le champ local de la visibilité.
Mais tout n'est pas si compliqué, là sont des choses évidentes. L'arrière-plan général de la page, l'arrière-plan et la couleur du texte principal, dans la plupart des cas, c'est ce qui définit le thème de votre application. Il est extrêmement pratique de rassembler des éléments qui sont responsables de la configuration d'un mode particulier (comme le mode sombre ou clair).
Pourquoi ne pas tout mettre dans la section racine?
J'ai eu une telle expérience. Sur le projet Lition l'équipe et moi étions confrontés au fait que nous devions supporter IE11 pour l'application Web, mais pas pour le site Web et les atterrissages. Un UI Kit commun a été utilisé entre les projets, et nous avons décidé de mettre toutes les variables à la racine cela nous permettra de les redéfinir à n'importe quel niveau.
Et aussi avec cette approche pour le web application et IE11, nous avons simplement passé le code à travers le plugin post-processeur suivant et avons transformé ces variables en littéraux pour tous les composants de l'interface utilisateur du projet. Cette astuce n'est possible que si toutes les variables ont été définies dans la section racine car le post-processeur ne peut pas comprendre les spécificités du modèle en cascade.
Maintenant, je comprends que ce n'était pas la bonne manière. Premièrement, si vous mettez les couleurs des composants dans la section racine, vous rompez le principe de séparation des préoccupations. En conséquence, vous pouvez vous retrouver avec du CSS redondant dans la feuille de style. Par exemple, vous avez le dossier des composants où chaque composant a ses propres styles. Vous disposez également d'une feuille de style commune dans laquelle vous décrivez les variables de couleur dans la section racine. Vous décidez de supprimer le composant bouton ; dans ce cas, il faut se rappeler de supprimer également les variables associées au bouton du fichier de styles communs.
Deuxièmement, ce n'est pas la meilleure solution en termes de performances. Oui, un changement de couleur entraîne uniquement le processus de repeindre, pas de redistribution / mise en page, cela en soi n'est pas trop coûteux, mais lorsque vous apportez des modifications au plus haut niveau, vous utiliserez plus de ressources pour vérifier l'ensemble de l'arbre que lorsque ceux-ci les changements sont dans une petite zone locale. Je recommande de lire le benchmark de performance des variables CSS de Lisi Linhart pour plus de détails.
Sur mon projet actuel Tispr l'équipe et moi utilisons split et ne vidons pas tout dans le racine, sur le haut niveau seulement une palette et des couleurs fonctionnelles. De plus, nous n'avons pas peur d'IE11, car ce problème est résolu par le polyfill correspondant . Installez simplement le module npm ie11-custom-properties et importez la bibliothèque dans le bundle JS de votre application:
// Utilisez la syntaxe ES6
import "ie11-custom-properties";
// ou CommonJS
require ('ie11-custom-properties'); Ou ajoutez un module par balise de script: