Project

General

Profile

Evolution #4720

[css vars] Utiliser nos variables CSS dans le thème de l'espace privé

Added by marcimat 🌻 29 days ago. Updated 11 days ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
espace privé
Target version:
Start date:
04/09/2021
Due date:
% Done:

0%

Resolution:

Description

Avec https://git.spip.net/spip/spip/pulls/141 est arrivé la définition de variables CSS dans l'espace privé de SPIP.
Il s'agirait maintenant de les utiliser partout dans l'espace privé :)

Elles sont (aujourd'hui) définies là https://git.spip.net/spip/spip/src/branch/master/prive/themes/spip/vars.css_fonctions.php#L32 dont certaines valeurs proviennent pour partie de https://git.spip.net/spip/spip/src/branch/master/ecrire/inc/couleurs.php#L40 et pour partie de https://git.spip.net/spip/spip/src/branch/master/prive/themes/spip/style_prive.css.html#L21

Les déclarations de style_prive.css.html devraient être uniquement en variables CSS, et les calculs éventuels fait ensuite avec calc() tel que padding: calc(var(--spip-css-line-height) / 2);
CSS est hyper sympa, il sait faire des calculs même s'il y a des unités sur ses valeurs.

Seuls left et right a priori ne sont pas remplacables tel quels, dans le nom des propriétés (on ne peut mettre de variable css dans un nom de propriété) :
- soit on continue à utiliser par exemple : margin-#GET{left}: ...
- soit on bascule sur margin-left: ... et on applique le filtre |direction_css sur le résultat du squelette ou fichier css (avec certaines imprécisions possibles avec ce filtre)
- soit, plus tard, un jour, on pourra utiliser les valeurs *-inline "margin-inline" https://caniuse.com/?search=margin-inline ; mais "float" n'est pas encore concerné par ce placement (https://caniuse.com/mdn-css_properties_float_flow_relative_values)

Dans la valeur par contre, nous avons la variable adaptée :
float: var(--spip-css-left);

On a à disposition pour les couleurs un jeu de variables dans la couleur du thème, et un jeu de niveau de gris

--spip-color-theme-white
--spip-color-theme-lightest
--spip-color-theme-lighter
--spip-color-theme-light
--spip-color-theme
--spip-color-theme-dark
--spip-color-theme-darker
--spip-color-theme-darkest
--spip-color-theme-black

--spip-color-white
--spip-color-gray-lightest
--spip-color-gray-lighter
--spip-color-gray-light
--spip-color-gray
--spip-color-gray-dark
--spip-color-gray-darker
--spip-color-gray-darkest
--spip-color-black

Ce sont les variables à utiliser préférentiellement pour les couleurs du privé.
Il conviendra de définir des variables sémantiques, tel que (--spip-color-border) pour certains usages fréquents, et pour faciliter l'homogénéisation des différentes pages.
Il existe d'autres variables de couleurs pour des usages plus spécifiques.

Ceci fait permettra de simplifier la lecture des CSS de l'espace privé, en éliminant en passant de CSS depuis des squelettes SPIP à des fichiers CSS directs, saufs pour certains cas très précis, mais limités.
Ça devrait permettre également d'homogénéiser ses couleurs.

Pour comparer les couleurs avant / après, on peut se baser en première approche sur l'image https://git.spip.net/attachments/a92cc317-b837-42b6-a00e-92d2a6c201e0 qui compare avec les couleurs calculées vs les variables CSS. Ça permet de dire tiens : "ce40" = "couleur claire | couleur éclaircir { 40 }" c'est à peu près --spip-color-theme-light => on le remplace par cette variable. Etc.

History

#1 Updated by nicod _ 29 days ago

Là, je pense que la proposition de Jluc de documenter les css va devenir utile...

#2 Updated by tcharlss 🐽 29 days ago

Ça simplifie énormément la vie et ça permet pleins de choses sympas, merci marcimat.
En plus des couleurs il y aura quelques autres variables d'utilité publique à ajouter par la suite pour homogénéiser aussi les espacements, les gouttières, etc.

#3 Updated by marcimat 🌻 15 days ago

Après quelques observations du comportement de `|direction_css` je pense qu'il faudrait totalement l'abandonner aussi dans le privé au profit des variables CSS

Donc, à la fois
- enlever les css compilées (.css.html) où on le peut, pour ne conserver que certainses spécificités (usages de boucles) sur quelques rares choses
- et ne pas remplacer (et enlever) `|direction_css`

Je m'explique.

Le filtre change tout ce qu'il voit de `left` ou `right` et l'inverse. Dans le nom des propriétés, et dans leurs valeurs. Pour certains propriétés (margin, padding et d'autres) il sait aussi inverser 4 valeurs (haut droite bas gauche) en (haut gauche bas droit).

Le problème est qu'il modifie aussi le nom des variables CSS elles-mêmes. La déclaration `--spip-left: left;` devenant alors `--spip-right: right;` ; de même `truc: var(--spip-left);` devient `truc: var(--spip-right);` ce qui ne sera pas pratique à l'usage.

Il y a plusieurs moyens de s'en sortir juste avec des variables CSS. Un exemple :

:root, 
html[dir=ltr]  {
  --spip-left: left;
  --spip-right: right;
  --spip-ltr: ltr;
  --spip-is-ltr: 1;
  --spip-is-rtl: 0;
}
html[dir=rtl] {
  --spip-left: right;
  --spip-right: left;
  --spip-ltr: rtl;
  --spip-is-ltr: 0; 
  --spip-is-rtl: 1;
}

On peut styler ensuite différents trucs, avec des calc() éventuellement, si on ne souhaite pas utiliser les (padding | margin | border)-block-(start | end). Il semble que `padding-block-start` ou `margin-block-end` sont assez bien compris (contrairement à margin-inline par exemple - https://caniuse.com/mdn-css_properties_margin-inline - https://caniuse.com/mdn-css_properties_margin-block-start)

Des exemples :

.old {
  margin-left: 10px;
  margin-#GET{left}: 10px;
}
.new {
  margin-block-start: 10px;
  /* ou a base de variables — mais ça oblige à écrire aussi le -right , ou une définition 'margin' à 4 valeurs */
  margin-left: calc(var(--spip-is-ltr) * 10px);
  margin-right: calc(var(--spip-is-rtl) * 5px);
}

.old {
  float: left;
  float: #GET{left};
}
.new {
  float: var(--spip-left);
}

.old .item_picker .frame.total_3 {
    margin-#GET{left}:-58px;
    border-#GET{left}:3px solid #GET{foncee};
}
.new .item_picker .frame.total_3 {
    margin-block-start: 58px;
    border-block-start: 3px solid var(--spip-color-theme);
    /* ou définir les 2 côtés avec les variables --spip-is-ltr et --spip-is-rtl */
}

À creuser.

Des avis sur l'utilisation des *-block-start | end ? Ce n'est pas tout à fait identique vu que si on écrit du texte verticalement la marge sera placée en haut ou bas.

#4 Updated by tcharlss 🐽 11 days ago

Ah oui bien les astuces à base de --spip-is-ltr.

Pour compléter sur le sujet des propriétés de positionnement, dans le futur, pour avoir le support complet quelque soit la direction (horizontale ou verticale) il faudra définir le writing-mode : https://developer.mozilla.org/en-US/docs/Web/CSS/writing-mode
Valeur qu'il faudrait pouvoir récupérer en fonction du code de langue, donc.
D'après ce que j'ai compris, en son absence ça se repose sur la direction du document (dir="rtl"), donc c'est bon pour les langues à l'horizontale.

Bref, on a donc pris un peu d'avance et commencé à utiliser tout de suite des variables CSS.
Le choix s'est fait un peu tout seul : ça simplifie énormément la tâche, surtout en l'absence de préprocesseur, et ça permet d'unifier et maintenir plus facilement tous les composants.

Par contre avant de poursuivre, il faudrait peut-être faire un petit point d'étape, voir rédiger des guidelines pour ne pas assister à une hyper-inflation de ces variables, et qu'elles ne soient pas utilisées à tord et à travers dans tous les sens.

La règle que j'ai suivie jusqu'à présent :

  • Des variables globales --spip-xxx, de portée générale et utilisables partout : couleurs, propriétés de texte, arrondis des blocs, gouttières, etc.
  • Et pour chaque composant, quelques variables qui lui sont propres : --composant-xxx. À quelques exceptions près, elles ne devraient pas être utilisées en dehors. J'essaie de limiter le nombre en général, une dizaine au max (sauf pour les boutons, un cas spécial).

Enfin, il y a 2 variables globales bien importantes qu'il va falloir mettre au point : ce sont celles qui définissent les gouttières horizontales et verticales. Importantes cas après, chaque composant se basera dessus pour ses propres besoins, et au final on aura des espacements bien harmonisés et facilement contrôlables.

Il peut s'agit d'une mesure arbitraire, mais en général pour la gouttière horizontale on prend l'équivalent d'une hauteur de ligne, c'est à dire font-size * line-height à la racine du document.
Je l'ai ajoutée en prévision (spip-spacing-y), sauf que pour l'instant elle est pas trop utilisable : le font-size qu'on reçoit dans l'env est pas celui qui est utilisé sur le body, donc ça fausse toutes les mesures. Le font-size du body est redéfini plusieurs fois d'affilée, c'est le bordel. Bref, encore des choses à mettre au point.

Also available in: Atom PDF