Comment configurer les jeux de couleurs d'application avec les propriétés personnalisées CSS

À propos de l'auteur

Artur est un ingénieur logiciel avec une forte interface et une forte concentration sur les tests. Il vit et travaille à Grodno, en Biélorussie, et est passionné par les technologies Web et tout…
En savoir plus sur
Artur
…

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: 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.

When you ' Si 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.

Voilà une option, mais cela vous aide-t-il à résoudre les problèmes de thématisation des applications, d'étiquetage blanc, de rafraîchissement de la marque ou d'organisation d'un mode clair ou sombre? Que faire si vous devez ajuster la palette de couleurs pour augmenter le contraste? Avec l'approche actuelle, vous devrez mettre à jour chaque valeur de vos variables.

Dans cet article, je souhaite 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

Configuration de la palette de couleurs

La coloration d'un 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 – des tons et des 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 schéma de couleurs triade en utilisant le service Paletton :

J'ai maintenant trois couleurs principales. Sur la base de ceux-ci, je vais calculer les tonalités 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.

Maintenant, si la palette est modifiée, alors il sera nécessaire de changer uniquement la valeur des couleurs primaires. Le reste sera recalculé automatiquement.

Si vous préférez les formats HEX ou RVB, cela n'a pas d'importance; 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 la fonction d'ajustement des couleurs ). Comme je l’ai déjà mentionné, cette couche est principalement statique; il est extrêmement rare que la palette soit modifiée dans une application en cours d’exécution. C’est pourquoi nous pouvons le calculer avec des préprocesseurs.

Remarque : 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 à l'avenir.

Le niveau de la palette est le seul niveau où la couleur est encodée directement dans les noms des variables, c'est-à-dire que nous pouvons identifier la couleur de manière unique en lisant le 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 et 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 arrière-plan clair, la couleur de l'arrière-plan du bouton, la couleur du lien, la couleur du lien de survol, la couleur du texte d'indication, etc.

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 en opérant simplement avec 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 précédemment 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 se produit en utilisant l'API CSSOM appropriée (setProperty) .

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, ce qui signifie que 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 morceaux de code puisse être appelé portée locale et réutilisé.

En général, je vois l'intérêt 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 d'application, sont répétés avec des paramètres différents, par ex. boutons pour différents besoins tels que le bouton principal (marque), le bouton secondaire, le bouton tertiaire, etc.

Le second est lorsque des composants qui ont plusieurs états avec des couleurs différentes, par ex. 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.

Dans l'exemple ci-dessous, j'ai maintenant ajouté des contrôles pour personnaliser les couleurs du primaire (marque ) bouton. 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.

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 trois 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:

La couleur gris foncé est répétée – c'est la bordure du champ de saisie, la couleur de remplissage de l'icône de fermeture et 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 uniquement 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:

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 des paramètres différents, 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.

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 pourrons déterminer ce qui est commun et devrait vivre au niveau fonctionnel, et ce qui devrait rester dans la portée locale 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 avons été 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 dans 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 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 . Il suffit d'installer module npm ie11-custom-properties et d'importer la bibliothèque dans le bundle JS de votre application:

 // Utiliser la syntaxe ES6
import "ie11-custom-properties";
// ou CommonJS
require ('ie11-custom-properties'); 

Ou ajouter un module par une balise de script:

  
 
Source link 
Partager :
Cliquez pour partager sur Twitter(ouvre dans une nouvelle fenêtre)
Cliquez pour partager sur Facebook(ouvre dans une nouvelle fenêtre)
Articles similaires