Recherche avancée

Sur d’autres sites (5020)

• Evolution #4720 (Nouveau) : [css vars] Utiliser nos variables CSS dans le thème de l’espace privé

  9 avril 2021

  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.

• Anomalie #4015 (Fermé) : Boucle DATA YQL requires https but requested through http

  14 octobre 2017, par Fabrice Véronneau

  Salut,

  Suite au message sur sur le forum (https://forum.spip.net/fr_268147.html)
  le message suivant apparait sur une requête concernant Flickr (mais sans doute d’autres services aussi)

  Table flickr.people.publicphotos requires https but requested through http

  En modifiant la ligne 639 de ecrire/iterateur/data.php ca fonctionne (https au lieu de http) :
  https://core.spip.net/projects/spip/repository/entry/branches/spip-3.2/ecrire/iterateur/data.php#L639

  Ca concerne ttes les versions de spip avec iterateur yql

• Anomalie #4623 : Styles des fieldset dans l’espace privé

  19 avril 2021

  Je pense qu’il faut garder la règle un fieldset == un div.editer en plus gros.

  Oui, ça se tient aussi. Je crois avoir vu cette structure utilisée sur un form de la dist d’ailleurs.
  Pour les fieldsets on pourrait employer un nom qui rappelle que ça fait partie d’un .editer-groupe non ? Genre .editer-fieldset par exemple, au lieu de .fieldset tout court ?

  Je signale pour pas oublier et ne pas exclure cette possibilité que certains formulaires ont besoin de plusieurs .editer-groupe à la racine, avec des choses entre. Par exemple pour le multi il y a des .boutons au milieu du formulaire :

  form
    .editer-groupe
    .boutons
    .editer-groupe
    .boutons
  

  On peut imaginer aussi un formulaire qui aurait besoin en cours de route d’un groupe de saisies en 2 colonnes, donc de plusieurs .editer-groupe consécutifs :

  form
    .editer-groupe
    .editer-groupe.deux_colonnes
    .editer-groupe
  

  Et aussi entre le legend et le .editer-groupe d’un fieldset, la charte permet d’insérer des explications (et autres ?).