[Résolu] Nommer des variables en CSS

Quand j'ai commencé à utiliser sass je nommai les couleurs avec un outil, dont j'ai oublié le nom, qui permettait de faire correspondre une couleur a un nom. Un outil un peu comme ça : http://chir.ag/projects/name-that-color/

Le problème de cette méthode et que les noms des variables ne sont plus explicites si on doit un jour remplacer du vert par du rouge. Même si en vrai on ne change que très rarement voir jamais les couleurs, il faut plutôt voir ces variables comme des constantes.

Ensuite j'ai utilisé des noms moins contextualisés comme $headings-color, $link-color. Dans tout les cas c'est vite imparfait lorsque l'on doit faire évoluer le site. Comment faire si par exemple le titre h2 passe dans une autre couleur, on se retrouve a faire un $headings-color-2 ?

A mon avis il n'y a solution parfaite.

Aujourd'hui, je n'utilise plus les variables pour les couleurs (ni pratiquement plus les variables tout court d'ailleurs) car avec les langages comme sass le code est déjà suffisamment factorisé et au final ces variables servent très peu. Pour changer une couleur il suffit de ctrl/cmd + f le code hex et de remplacer.

Un exemple de code que j'ai utilisé pour la titraille :

.h1, .h2, .h3, .h4, .h5, .h6 {
	font-family: 'Ubuntu', Helvetica, Arial, sans-serif;
	display: block;
	font-weight: 400;
	line-height: 1.15;
        color: #000000;
	
	&.light {
		font-weight: 300;
	}
	
	&.strong {
		font-weight: 700;
	}
	
	&.white, .white {
		color: #FFF;
	}
	
	&.blue, .blue {
		color: #006aa8;
	}
	
	&.grey, .grey {
		color: #828282;
	}
	
	&.light-underlined {
		border-bottom: solid 1px #bdbdbd;
		padding-bottom: 6px;
	}
	
}

Avec les liens et la couleur de base du site c'est pratiquement tout ce dont on a besoin pour définir les couleurs des textes du site.

Pour les blocs comme ceux sur fond noir/beige je fais des classes vraiment basique.

.white-section {
    background-color: #f5f5f5;
}

.black-section {
    background-color: #1a1a1a;
    color: #FFF;
    .h1, .h2, .h3, .h4, .h5, .h6 {
        color: #FFF;
    }
}

et c'est tout.
Modifié par Depassage (15 Mar 2019 - 10:10)

Je suis d'accord avec le message précédent. J'ai moi-même utilisé les variables à outrance, dans une logique jusqueboutiste (exemple), au final non seulement cela n'aidait pas à la maintenabilité mais ça la désservait.

_laurent a écrit :

mmmmm même si tu colles la couleur en dur tu vas devoir faire une autre classe avec une autre règle etc. La seule diff est que tu assignes une variable plutôt qu'une couleur (et avec un peu de chance la variable est déjà définie donc ca met pas plus de temps).
Histoire d'avoir des couleurs déjà définies (comme le vert ou le rouge) avec un nom sympa plutôt qu'un code hexa imbitable. Comme ca même les dev back sont capable de faire une color:$red; sans foutre en l'air le design de l'appli. Et on se retrouve pas avec des #F5F5F5, #F8F8F8 et #F0F0F0 en pagaille (réinventer, volontairement ou involontairement, la couleur a chaque fois qu'on fait un nouvel élément).

Je t'accorde le nom sympa. Pour le reste j'explique plus bas la problématique de la réutilisation à outrance de ces variables.

_laurent a écrit :

- quand le site est en court de développement et que la couleur principale peut encore bouger (même un tout petit peu : mince notre bleu passe mal sur téléphone)

C'est un problème de se retrouver à changer des couleurs alors que l'intégration est en route. Ça veut dire que le client n'a pas clairement intégré le processus de validation et qu'il risque d'y avoir des problèmes à venir.

D'autre part les variables ne font pas gagner de temps pour modifier une couleur sauf si tu n'utilise jamais la cascade, l'héritage, les sélecteurs multiples, bref ce que permet déjà css.

_laurent a écrit :

- Pour faire de la personnalisation des couleurs de l'interface en fonction du compte connecté par exemple, ou même en fonction de l'heure (effet coucher de soleil !).

Tes variables ne permettent pas de changer la couleur de ton interface avec sass. Pour ça tu vas devoir de toute façon créer une nouvelle classe et définir de nouvelles couleurs.

_laurent a écrit :

- Quand le client dit que le rouge des erreurs ne se voit pas assez : il y a juste a changer le $red. Si tu as collé les code hexa en dur il y a de grande chance que pour les variations (fond plus clair, tour plus foncé) tu ais aussi laissé le code en dur et dur coup il faut repasser sur plusieurs codes hexa avec un ctrl + maj + F pour etre sur de bien aller chercher dans tout les fichiers du projets, faire le tour du site et cliquer partout pour etre sur de pas en avoir oublier un etc. Et on croise les doigt pour ne pas avoir fait une faute de frappe dans le code des couleurs (entre #C62828 et #C62829 il n'y a qu'un pas, mais le ctrl + F ne le fera pas !).

Ton $red sera utilisé logiquement à un seul endroit, probablement sur une classe pour les messages d'erreurs. Si tu commences à définir des couleurs globales et à les utiliser à la fois pour des contours, des messages d'erreurs, des backgrounds, etc... tu vas avoir des problèmes lorsque ton dev, qui d'ailleurs n'a rien à faire dans ces fichiers , va modifier cette couleur en croyant modifier uniquement les messages d'erreur et se retrouver avec le fond d'un bloc lambda en rouge vif en conséquence. En modifiant une couleur pour améliorer le contraste ici, tu vas peut être le détériorer à un autre endroit. Car tu n'as aucun moyen de savoir ce que tu modifies sauf à vérifier chaque endroits où tu as collé ton $red. Bref tu perds tout le bénéfice de tes variables.

C'est pour ça que, comme je le disais plus haut, il faut voir ces variables de couleur comme des constantes. Car les utiliser comme des variables crée des effets de bord.

Autrement, je suis personnellement très rigoureux sur mes codes hexadécimaux.

D'une manière générale il faut voir un site web comme fini à un instant T et pas comme quelque chose qui va pouvoir évoluer sans cesse et être modulaire à l'infini. Je pense - car moi même je l'ai cru/ai eu cet objectif de modularité - que certains pensent achever cela en créant de nombreuses variables permettant de 'configurer' le site tel que dans l'exemple de Olivier C. En faisant évoluer le code on détériore ce qui existe déjà en créant de nouvelle classes, de nouvelle variables et parfois c'est un peu sale car on doit surcharger tout un tas de propriétés. Bref le code ne reste jamais parfait longtemps même si on essaye de le tenir du mieux possible. Au bout de 4 à 5 année le site sera très certainement refait de zéro et le code disparaîtra dans l'oblivion.