J’ai commencé une nouvelle branche pour voir ce que je pouvais faire avec les CSS de l’admin de Dotclear, afin de passer aux variables CSS plutôt que d’utiliser les variables Sass et possiblement prévoir plusieurs jeux de couleur, d’une part, et d’autre part d’implémenter un mode automatique en fonction du choix de l’utilisateur du côté de son système d’exploitation.
Ça se fait avec la mediaquery prefers-color-scheme.
Premier jet de modifs hier, et j’arrive avec, tenez vous bien, plus de 230 variables CSS pour la seule gestion des différentes couleurs sémantiques.
Du coup la question que je me pose est la suivante : « Est-ce que c’est raisonnable d’un point de vue gestion, performance, d’avoir autant de variables CSS ?
Et comme je n’ai aucun background à ce sujet, si jamais quelqu’un passant par là pouvait m’éclairer sur les bonnes pratiques dans ce domaine…
1 De Da Scritch -
Cela ne me choque pas tant que ça, car chaque variable devient réellement réutilisable tout en s’appliquant qu’à un groupe de propriétés.
Pour mon web-component, j’ai eu la même question, https://github.com/dascritch/cpu-au… et finalement, j’ai encore ajouté des variables internes. Et ça reste 100.000× mieux que les “variables” sass qui sont impossibles à modifier depuis le navigateur en temps réel.
Standards roxor, as usual.
2 De Emmanuel -
230 couleurs différentes pour l’admin de Dotclear !? Aurais-tu moyen d’en sortir une palette pour se figurer la chose ? Je ne serais pas surpris qu’elle puisse être simplifiée ou que certaines puissent être modifiées avec des effets de transparence.
J’ai tendance à penser que c’est à ce niveau qu’il faudrait économiser d’abord.
Sinon, je dis comme Da Scritch. Et effectivement, côté utilisateur ça peut devenir intéressant, de pouvoir générer sa propre palette (même si dans les faits je pense que personne n’ira jusqu’à opérer une personnalisation si importante).
3 De Franck -
Emmanuel quand je parle de 230 couleurs, ce sont des noms de variable sémantiques, du genre —body-color.
La palette réelle comporte beaucoup moins de couleurs, une trentaine pas plus, et dont pas mal ont des cas d’usage très spécifiques.
4 De Nicolas Hoizey -
Les Custom Properties et les variables Sass n’ont pas le même usage, puisque les premières profitent de la cascade, mais pas les secondes. J’utilise les deux. Aucun besoin d’utiliser uniquement des Custom Properties quand on peut garder Sass (ou autre) dans son outillage de dev, pour les variables dont les valeurs sont statiques (donc sont plutôt des constantes).
À minima, pour éviter les (légers) problèmes de performance des Custom Properties, il faut éviter de toutes les mettre dans
:root
:https://lisilinhart.info/posts/css-…
5 De Nicolas Hoizey -
Tiens, un excellent article paru il y a quelques heures qui pourrait t’aider à bien gérer des thèmes avec les Custom Properties :
https://css-tricks.com/using-custom…
6 De Franck -
Merci Nicolas !
J’ai conservé toutes les “constantes” (aka les codes couleurs essentiellement) sous forme de variables Sass, ce sont uniquement les « couleurs sémantiques » qui ont basculé sous forme de Custom Properties.
7 De Cunegonde -
Ça va être encore plus beau que d’habitude !
8 De Franck -
Alors en fait, non, à part qu’on pourra beaucoup plus facilement créer un autre thème pour l’administration.