Récrire les CSS avec des variables CSS

@marcimat a ajouté ce ticket au jalon spip-5.0

@marcimat a ajouté le label amélioration

Très bonne idée.

Et tant qu'à faire je suggère quelque chose qui pourrait aller de concert : permettre de choisir la couleur d'accent dans le privé. Pas dans le core hein, ça serait la dist qui ajouterait cela quelque part dans une des pages de config du privé (squelettes, identité ou autre).

(si ça complique trop ce ticket on peut voir ça dans un autre)

@marcimat : si tu poses le canevas pour déclarer les variables, je peux m'occuper de la réécriture ensuite.

Par "poser le canevas" je veux dire : soit du php qui génère un truc à la volée, soit un squelette, soit une css lambda. Ou une combinaison ? Ça dépend si on veut pouvoir y récupérer des valeurs de config ou pas. Enfin je te laisse voir le mieux :)

Oui, je pense qu’une idée simple serait de déclarer un :root avec des couleurs par défaut d’une part, et qu’un :root calculé (une config dans le privé) pourrait surcharger pour ce que tu dis… Tout dépend de jusqu’où aller ensuite.

Il faudrait regarder si y aurait pas des choses à reprendre dans le squelette Osmose où j’avais des jeux de couleurs proposés (en json) mais surtout des moyens de calculer des couleurs extrêmes (clair ou sombre pour les écritures contrastées en fonction du background), en CSS, mais c’était peut être pas parfait. Mais on voit le résultat qui change directement dans la config publique (hormis les parties qui était calculées avec scssphp).

L’essentiel du JS est dans ces coins

@marcimat pour ce genre de calculs génériques sur les couleurs, j'avais fait un micro plugin super pratique ici : https://git.spip.net/spip-contrib-extensions/cssvar/src/branch/master/cssvar_pipelines.php#L79

Ensuite avec ça c'est super facile dans un thème d'écrire en clair ou foncé suivant la détection que les couleurs (primaire, secondaire etc) sont elles mêmes claires ou foncées.

Par ailleurs ça permet de déclarer toutes autres variables aussi, dans n'importe quel sélecteur (la plupart du temps on met dans ":root" mais ça peut parfaitement être autres choses, par ex couleurs par rubrique etc).

L'utilisation intégrateurice est tout con :

/**
 * Déclarer les couleurs à utiliser
 */
function monplugin_cssvar($flux) {
	// Hors contexte, pour toutes les pages
	if (empty($flux['args'])) {
		$flux['data'][':root']['--color-primary'] = lire_config('monplugin/theme/color-primary', '#DE4237');
		$flux['data'][':root']['--color-secondary'] = lire_config('monplugin/theme/color-secondary', '#E35D3F');
		$flux['data'][':root']['--color-complementary'] = lire_config('monplugin/theme/color-complementary', '#FFF33C');
		$flux['data'][':root']['--color-neutral'] = '#817C7E';
	}
	
	return $flux;
}

Les deux buts étaient :

en très très peu de lignes de PHP, pouvoir avoir des choses dynamiques venant de configs dans les CSS, et ça aussi bien pour du statique site complet, que pour telle ou telle page précise
avoir des automatismes ajoutées, en premier lieu pour les couleurs, sans avoir à y penser

Ah mais l’intérêt était que c’était uniquement en CSS à partir des données H,S,L de la couleur (calculée en JS quand on modifie l’input color), donc tout se faisait côté navigateur, c’est pour ça que tu peux avoir un aperçu «en live» en gros de ce que tu choisis.

Et oui, si tu fais côté PHP, c’est totalement différent, y a pas besoin de se compliquer la vie réellement, on a déjà des fonctions pour le calculer en PHP.

Cependant je vois que ta méthode d’ajouter une classe dark ou light en fonction de la luminosité perçue pourrait aussi aider pour totalement passer un fond de page en clair ou foncé, mais dans mon idée je trouve ça mieux que ce soit indépendant de la couleur choisie (dark ou light passerait le thème en jour / nuit en conservant les couleurs choisies quoi). Je sais pas si c’est vraiment faisable avec n’importe quel choix de couleurs, mais c’est à creuser.

Quitte à rêver, idéalement le thème se colore (fond clair / foncé) selon le choix que tu as mis sur ton OS en priorité, puis selon ton choix via un cookie conservé (ou selon le choix imposé par le webmestre pour le site). En gros, par défaut ça utiliserait prefers-color-scheme, et sinon on ajoute une classe (theme--dark ou theme--light) sur le body en fonction de la préférence visiteur ou du site, qui prendrait le pas… qqc comme ça,

Je n'ai pas compris ta réponse @marcimat : mes automatismes ne concerne QUE des ajouts d'informations HSL luminosité etc justement pour pouvoir tout faire uniquement en CSS ensuite sans avoir aucune couleur en dur de généré, notamment pour quand on veut faire une variante. Il n'y a rigoureusement aucune variante de couleur générée dans les automatismes PHP.

Le dark et light ne sert pas à faire des thèmes dark ou clair, et ya aucune classe ajoutée, ça sert à savoir la luminosité perçu de chaque couleur du thème, pour ensuite savoir comment écrire par dessus uniquement en CSS, pour les composants CSS où on veut écrire sur des aplats de couleur (savoir si on doit écrire dessus en noir/foncé, ou en blanc/clair).

Exemple d'utilisation dans le CSS d'un thème (par ex pour comment écrire sur des boutons qui sont avec l'aplat de la couleur primaire, et là ça génère juste noir ou blanc mais ça peut parfaitement être teinté) :

color: hsl(0, 0%, calc((var(--color-primary--lightness) - var(--threshold)) * -10000000%));

Je suis allé un peu vite en besogne, il y a quand même un problème avec cette histoire de configuration des couleurs dans le privé : la dist n'est pas un thème que l'on peut désactiver.

Ça veut dire qu'en utilisant un autre jeu de squelettes ou thème, ces options de configuration n'auraient aucun effet, apportant moulte confusion aux admins.

Ou alors il faudrait que les plugins squelettes/thème puisse déclarer explicitement "oui, j'implémente cette configuration du thème" et elle serait affichée uniquement dans ce cas ? Avec possibilité de l'étendre s'ils veulent ? Bon, je veux pas trop compliquer le périmètre de ce ticket :)

Sinon oui @marcimat, bonne idée pour le thème clair/sombre.

Bref pour la dist, je pense que ça pourrait rester simple : on choisit la couleur d'accent, le mode clair/sombre, et basta.

Bref pour la dist, je pense que ça pourrait rester simple : on choisit la couleur d'accent, le mode clair/sombre, et basta.

@tcharlss +1 pour la simplicité, on verra bien par la suite si des gens veulent faire des choses plus "globales".

Oui, pardon @rastapopoulos j’ai peut être été un poil trop vite, mais donc tu crées

--$variable--lightness (float)
--$variable--is-dark (bool)
--$variable--is-bright (bool)

Et effectivement ces valeurs on pourrait aussi les calculer en JS pour un aperçu live.

Du côté de Osmose, j’avais des trucs très compliqué pour scssphp dont pour sûr y aura pas besoin heureusement ! Et ça c’est la joie.

En css de mon côté ça donnait ce résultat par exemple, avec des calculs à base de clamp (enfin qui n’existait pas sur safari y l’époque donc j’utilisais min et max pour le faire).

Ça fait un peu vaudou en CSS quand même les calculs.

<div class="bg-primary bg-darkest text-contrast">30%</div>

.text-contrast {
  color: hsl(var(--bg-h), calc(var(--bg-s) * 1%), calc((-2500 * (var(--contrast-ratio) * 1% / 100 + 1%)) / (var(--bg-lc) - 49.999) + var(--bg-lc) * 1%));
}
.bg-darkest {
  --bg-c: -30;
}
.bg-primary {
  --bg-h: var(--primary-h);
  --bg-s: var(--primary-s);
  --bg-l: var(--primary-l);
  --bg-a: var(--primary-a);
  --bg-c: var(--primary-c, 0);
  --bg-lc: max(0, min(calc(var(--bg-l) + var(--bg-c, 1)), 100));
  background-color: hsla(var(--bg-h), calc(var(--bg-s) * 1%), calc(var(--bg-lc) * 1%), var(--bg-a)) !important;
}
:root {
  --primary: #a27f06;
  --primary-h: 47;
  --primary-s: 93;
  --primary-l: 33;
  --primary-a: 1;

  --primary-c: 0;
  --primary-lc: max(0, min(calc(var(--primary-l) + var(--primary-c, 1)), 100));
  --contrast-ratio: 30;
}

Impossible de retrouver d’où viennent ces calculs là tout de suite.

Mais voir aussi https://stackoverflow.com/questions/596216/formula-to-determine-perceived-brightness-of-rgb-color

Et le complet https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_Colors_and_Luminance

Note d’ailleurs que j’ai un doute sur la formule que tu appliques où tu fais un calcul du lightness avec les coefficients R * coef, alors que Mozilla indique d’utiliser sRGBtoLin(R) * coef (un calcul en plus donc), du moins j’ai l’impression. Mais c’est peut être une approximation. Mais pour une approximation, ils semblent utiliser une autre formule avec des puissances de 2.2.

https://developer.mozilla.org/en-US/docs/Web/Accessibility/Understanding_Colors_and_Luminance#calculating_relative_luminance

@marcimat comme indiqué dans le premier log, c'était censé être la formule Luma du W3C, mais effectivement tu as raison, Wikipedia et le wiki du W3C ont l'air de faire des calculs en plus sur R/G/B avant le coeff : https://www.w3.org/WAI/GL/wiki/Relative_luminance https://en.wikipedia.org/wiki/Relative_luminance#Relative_luminance_and_%22gamma_encoded%22_colorspaces

@tcharlss

Je suis allé un peu vite en besogne, il y a quand même un problème avec cette histoire de configuration des couleurs dans le privé : la dist n'est pas un thème que l'on peut désactiver.

Ça veut dire qu'en utilisant un autre jeu de squelettes ou thème, ces options de configuration n'auraient aucun effet, apportant moulte confusion aux admins.

Alors je pense qu’on peut s’en sortir de 2 moyens

Dire "Certains squelettes peuvent utiliser les couleurs définies ici…" (et hop le tour est joué
ou mettre la configuration dans dist et dans le public avec une page spécifique qui permet un rendu instantané (cf Osmose)

Ça à l'air sympa Osmose :)

@marcimat ok pour la config, à réfléchir alors.

Je propose de faire en 2 temps mais dans le sens inverse finalement : d'abord les css avec des variables en dur, puis ensuite intégrer un système de configuration si on a le temps et l'envie.

@b_b pointait cela https://modernfontstacks.com/ Peut être qu’un sélecteur de police aussi peut être sympa en plus de la couleur : ici sans aucune font-face ajoutée, si je comprends bien.

Ah très intéressant ce site. J'en étais resté aux vieux font stacks d'il y a des années.

No downloading, no layout shifts, no flashes — just instant renders.

Oui dans ce cas, ça pourrait être un ajout facile et sympa.

Pour tenir au courant : j'ai entamé une branche avec les variables CSS + thème clair / sombre de mon côté, mais c'est pas encore assez mûr pour commiter, même en WIP.

Avant j'ai un problème à résoudre : il faut trouver une méthode correcte pour gérer les thèmes sombre / clair, pour l'instant ça oblige à dupliquer pleins de règles css et c'est pas satisfaisant, code lourd et compliqué à maintenir. J'ai vu une nouvelle méthode qui avait l'air prometteuse récemment, faudra que j'investigue.

Ah retrouvé, c'était ça : https://thinkdobecreate.com/articles/simplified-dark-mode-with-style-queries/

Ça se base sur des @container style, c'est donc pris en charge que par les navs bien récents malheureusement, 42% pour l'instant, même pas firefox :(

Mais ça me semble vraiment être la seule solution valable, avec l'ancienne méthode on se retrouve avec des css usines à gaz non maintenables.

Très prometteur ce truc de @container style(). Mais il semble qu’il faille attendre encore pour FF, Safari et Opéra… Pas de bol

Pour les thèmes OS / light / dark, je vois que chez https://developer.mozilla.org/fr/ ça utilise 2 choses :

une classe sur le <html>
une clé theme dans le localStorage

Et ça (en scss)


.light {
  @include light-theme;
}

.dark {
  @include dark-theme;
}

// OS Default.
:root:not(.light):not(.dark) {
  @media (prefers-color-scheme: light) {
    @include light-theme;
  }

  @media (prefers-color-scheme: dark) {
    @include dark-theme;
  }
}

Qui duplique donc tout un cas de déclarations de variables CSS

53% le @container style (faut attendre encore !)

@marcimat Intéressant, certes ça duplique des choses dans la css compilée, mais pas au niveau des sources, au moins de cette façon ça reste maintenable. Bon, uniquement en scss, dommage.

D'un autre côté on pourrait considérer ça comme de l'amélioration progressive pas vraiment essentielle et donc utiliser @container-style tout de suite, même si c'est pas encore beaucoup supporté.

Cool. Cela serait vraiment un plus si on pouvait gérer le thème light/dark.

Ne pas oublier de mettre à jour l'article après : https://www.spip.net/ecrire/?exec=article&id_article=5720

@tcharlss a référencé ce ticket depuis une révision feat: ajout de variables CSS

@tcharlss a fait référence à ce ticket depuis !4870 feat: ajout de variables CSS

Il y a donc une PR pour le sujet principal du ticket : !4870 (merged)

Pour le thème clair/sombre je pense qu'on pourra faire un ticket et une PR séparées, à la suite de celle-là.

@tcharlss a fait référence à ce ticket depuis #4871 Ajouter une configuration pour l'apparence du thème

@tcharlss a fait référence à ce ticket depuis #4872 Thème clair / sombre

@marcimat a référencé ce ticket depuis une révision docs(changelog): Pour #4865 (variables CSS)

Récrire les CSS avec des variables CSS

Designs

Éléments enfants ...

Activité

Message de l'administrateur

Récrire les CSS avec des variables CSS

Activité