28172 sujets

CSS et mise en forme, CSS3

[Résolu] Nommer des variables en CSS

Bonjour,

Je veux obtenir votre avis sur la façon (ou méthodes) que vous utilisez pour nommer vos variables en CSS (en utilisant un préprocesseur). J'ai lu beaucoup d'avis à ce sujet mais je souhaite obtenir d'autres.

En vous basant sur cette maquette:
https://p.w3layouts.com/demos/mairala/web/

Comment nommeriez-vous les variables ?


$black:    #000000;
$black-2:  #303030;
$blue:     #89c4f4;
$brown:    #7b6c63;
$grey:     #949494;
$grey-2:   #929292;
$grey-3:   #5f5f5f;
$white:    #ffffff;


Merci Smiley smile
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.
Modérateur
Salut,

Ça m’intéresse aussi d'avoir d'autres avis !

Après moultes réflexions et projets j'arrive à :

- une variable $main-color (déclinée si'il le faut en light et dark)
- les couleurs de base (rouge, vert, bleu etc) qui n'y sont qu'une seule fois j'ai comme toi $red, $green, $blue etc. pour les déclinaison je fais ca directement dans le CSS sans faire de variable ex : background-color: lighten($red,30%); ou rgba($red,0.2);
- des couleurs fonctionnelles $error, $valid, $infos (même si j'ai souvent $valid=$green; au moins je sépare les vert et les validation au cas où ça change un jour)
- les gris par contre je m'y suis perdu un peu.
> Je faisais $grey-1 $grey-2 $grey-3 mais je ne m'y retrouvais plus. Du coup j'ai commencé à mettre une partie du code dans le nom $grey-92 pour le #929292 mais là la variable perd tout son sens, autant mettre la couleur directement. Du coup j'ai commencé à donné des noms fonctionnels $grey-dark $grey-light en limitant au max leur nombre et de gérer les mini déclinaison comme les couleurs.
Récemment on a utilisé les couleurs du gris-bleu material donc nos variables reprennent les code couleurs de la palette material :
$greyblue-50: #ECEFF1;
$greyblue-100: #CFD8DC;
$greyblue-200: #B0BEC5;
$greyblue-300: #90A4AE;
$greyblue-400: #78909C;
$greyblue-500: #607D8B;
$greyblue-600: #546E7A;
$greyblue-700: #455A64;
$greyblue-800: #37474F;
$greyblue-900: #263238;

Donc au final on en revient au début.

Je pense comme Depassage qu'il n'y a pas de solution parfaite. C'est a voir selon ton expérience, tes goûts et ceux de ton équipe si tu bosses en team etc...

Par contre je ne rejoins pas du tout Depassage ou Olivier C sur le fait de ne plus les utiliser. Déjà parce-que j'ai des projets énormes au travail, et même pour les petits sites, je trouve ca vraiment très pratique. Je suis même passé aux variables CSS natives.

Je les utilise beaucoup aussi pour les tailles en px de certains éléments.

Bonne continuation !
D'ailleurs, je crois que j'ai arrêté de les utiliser quand je me suis dit qu'en fait écrire cela :

$color: #f5f5f5;

// ... plus loin

.white-section {
    background-color: $color;
}


n'apportait aucune flexibilité relativement à cela :
.white-section {
    background-color: #f5f5f5;
}


Demain si je veux modifier une section et lui donner une autre couleur, je vais devoir créer une nouvelle variable et faire une autre règle css avec un background-color auquel j'attribuerai cette nouvelle variable. Autrement dit je vais juste mettre plus de temps a faire un truc qui de base était très simple.

Le seul cas ou c'est utile, question maintenabilité du code, c'est si l'on veut modifier les couleurs de tout un site d'un seul coup. Mais c'est très peu probable que vous ayez jamais à faire cela, le site sera certainement recodé entièrement le jour où le design sera refondu.

L'autre cas où ça pourrait être utile c'est en utilisant un nuancier présent dans je ne sais quel IDE ou avec de l’auto-complétion si vous vous souvenez du nom que vous donnez à vos variables. Mais personnellement je trouve que ces variables restent utilisées à trop peu d'endroits pour que cela soit nécessaire.

Après fondamentalement rien n'est faux c'est juste un équilibre à trouver au bénéfice du workflow. Smiley cligne
Modifié par Depassage (15 Mar 2019 - 15:27)
Modérateur
Depassage a écrit :
Demain si je veux modifier une section et lui donner une autre couleur, je vais devoir créer une nouvelle variable et faire une autre règle css avec un background-color auquel j'attribuerai cette nouvelle variable. Autrement dit je vais juste mettre plus de temps a faire un truc qui de base était très simple.

Smiley confuse 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).

Depassage a écrit :
Le seul cas ou c'est utile, question maintenabilité du code, c'est si l'on veut modifier les couleurs de tout un site d'un seul coup. Mais c'est très peu probable que vous ayez jamais à faire cela, le site sera certainement recodé entièrement le jour où le design sera refondu.

Je m'en sert à plusieurs occasions :
- 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)
- 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 !).
- 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 !).

Bref. Comme tu le dis :

Depassage a écrit :
fondamentalement rien n'est faux c'est juste un équilibre à trouver au bénéfice du workflow

Faut trouver une solution qui te vas a toi, ton projet et a ta façon de bosser.

Bisous bisous
_laurent a écrit :

Smiley confuse 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 Smiley cligne , 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. Smiley langue

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.
Juste pour préciser mon premier message par rapport à une remarque de _laurent : je ne pense pas qu'il ne faut "plus du tout les utiliser", mais à bon escient...
Bonjour à tous Smiley smile

Je remercie tout le monde pour leur participation. Vous m'avez permis d'y voir plus clair. Je vois que chacun à une méthode différente, donc je pense que le mieux est d'adapter en fonction du projet et de rester ouvert d'esprit.

Je ferme le sujet Smiley smile
Sujet clos
Aller à