Recherche avancée

Sur d’autres sites (9649)

• Evolution #4641 (Nouveau) : Des rechargements Ajax avec des transitions personnalisables

  27 janvier 2021

  En me penchant sur les librairies JS de transitions entre pages telles que https://barba.js.org ou https://swup.js.org, je me faisais la réflexion qu’on a déjà quasiment tout ce qu’il faut dans Spip pour avoir l’équivalent avec les rechargements de blocs Ajax.

  Il ne s’agirait pas d’ajouter une ces libs hein, mais juste d’étendre le mécanisme actuel dans ajaxCallback.js, ce qui devrait permettre de reproduire la chose à peu de frais (pour les blocs ajax, pas des pages entières donc).
  Je n’ai pas encore regardé en détail, mais il semblerait qu’il ne manque pas grand chose.

  Pour rappel, ces libs reposent entièrement sur des animations CSS pour les transitions, animations personnalisables au cas par cas : c’est souple et facile à personnaliser.
  Des classes sont ajoutées au conteneur pour indiquer chaque étape (couplé à des events JS) : quand l’ancien contenu part, quand le nouveau arrive, etc.
  Exemple pour Swup : https://swup.js.org/getting-started/how-it-works.
  Exemple pour Barba : https://barba.js.org/docs/getstarted/lifecycle/

  Pour nos rechargements ajax c’est déjà un peu pareil, il y a plusieurs étapes (début du chargement, fin du chargement), sauf que les styles CSS sont mis en dur : .css('opacity', 0.5)

  Donc ce que j’imagine, c’est ça :

  • Ne plus mettre des styles en dur, mais des classes CSS. Par défaut il s’agirait par exemple de .ajax-transition-defaut.
  • Découper le chargement en autant d’étapes que nécessaires, chaque étape appliquant une classe au bloc, par exemple : .ajax-loading-beforeleaving, .ajax-loading-isleaving, .ajax-loading-afterleaving, etc.
  • Chaque étape ne doit appeler la suivante qu’une fois l’animation (optionnelle) de l’étape précédente terminée. C’est une chose possible en JS (attendre la fin de l’anim du bloc ciblé). Par exemple si un⋅e intégrateur⋅ice décide que son animation de départ et d’arrivée prend 10s, ça la regarde, on n’impose rien.
  • Enfin, permettre de choisir l’animation désirée pour chaque bloc, au cas par cas. Il pourrait s’agir par exemple d’un paramètre réservé en complément de `ajax` :

  Le but c’est que ça reste facilement prenable en main par les intégrateurs et intégratrices.

  Exemple concret.

  Mettons que je veuille une animation personnalisée pour un bloc, je lui donne un identifiant :

  <span class="CodeRay"><span class="tag">span><span class="error">{</span><span class="attribute-name">fond</span>=<span class="attribute-value">truc</span><span class="error">,</span> <span class="attribute-name">ajax</span>=<span class="attribute-value">machin</span><span class="error">,</span> <span class="attribute-name">ajax_transition</span>=<span class="attribute-value">mojito</span><span class="error">}</span><span class="tag">></span>
  
  </span></span>

  La transition personnalisée est ajoutée comme classe au bloc ajax, ainsi que l’étape actuelle mise à jour au fil du chargement :

  <span class="CodeRay"><span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">ajaxbloc ajax-id-machin ajax-transition-mojito ajax-loading-[etape_du_chargement]</span><span class="delimiter">"</span></span> <span class="attribute-name">data-ajax-env</span>=<span class="string"><span class="delimiter">"</span><span class="content">…</span><span class="delimiter">"</span></span><span class="tag">></span>
  
  </span></span>

  Il reste juste à créer les styles pour chaque étape de cette transition, et on fait absolument ce qu’on veut : flip en 3D, translation…
  Nb : il n’est pas toujours nécessaire d’avoir des styles pour toutes les étapes, ça dépend de ce qu’on veut.

  <span class="CodeRay"><span class="class">.ajax-transition-mojito</span><span class="class">.ajax-loading-beforeleaving</span> {<span class="error">…</span> }
  <span class="class">.ajax-transition-mojito</span><span class="class">.ajax-loading-isleaving</span> {<span class="error">…</span> }
  <span class="class">.ajax-transition-mojito</span><span class="class">.ajax-loading-afterleaving</span> {<span class="error">…</span> }
  // <span class="tag">etc</span>.
  </span>
  Télécharger

  Et donc pour la transition par défaut, il y aurait son équivalent en CSS fourni par Spip, avec l’opacité à 50% etc.
  Et personnalisable facilement également si on le souhaite.

• Anomalie #4562 : Suite #4468 : Unification des CSS pour les boutons et les icônes

  9 octobre 2020

  la hiérarchie est alors super bien cohérente avec le sens de chaque élément

  J’arrivais pas à mettre le doigt dessus exactement sur ce qui me faisait tiquer, mais en fait crois que c’est ça.
  La hiérarchie est cohérente dans cette zone de la page – en gros ce qu’il y a à l’intérieur et autour de afficher_milieu – ça je suis d’accord.

  Mais quand on considère la page dans son ensemble, du coup ces boutons primary me semblent plus attirer l’attention que le bouton pour modifier l’article. Et par ordre d’importance c’est quand même lui le bouton principal de la page, qu’on est censé cliquer le plus souvent. Il est certes plus grand mais l’oeil est quand même plus attiré par des blocs avec du texte blanc sur fond sombre.

  C’est pour ça que des .link me semblent une option acceptable dans ce cas.
  Même avec cette variante je pense qu’on identifie quand même rapidement qu’il s’agit de boutons : ils sont à droite comme tous les autres boutons, ils sont en gras avec des icônes de couleurs vives, et surtout une fois qu’on s’en est servi une fois, bah voilà, l’info est gravée dans le cerveau.

  Après je sais pas, si ces choses étaient pas collées en plein milieu de la page, peut-être que ça me poserait moins problème que des boutons attirent plus l’attention. Moi j’ai un problème avec ce affiche_milieu :p

• Anomalie #4562 : Suite #4468 : Unification des CSS pour les boutons et les icônes

  6 octobre 2020

  Ouais, trois tailles suffisent je pense. Normal sans classe. Plus petit. Plus grand.

  Donc je suis parti sur 2 variantes .mini et .large, ça devrait suffire.
  On peut également les mettre sur un groupe de boutons, ça évite d’avoir à les mettre sur chaque bouton du groupe.
  Ça c’est commité.

  

  Autre sujet : les espèces de pseudo boutons avec des crochets qu’on trouve dans les .toggle_box_link : [Changer], [Ajouter une patate]… Notamment dans le formulaire editer_liens.
  Tant qu’à fignoler, je suis d’avis de supprimer ces crochets.
  À priori juste avec les classes .link.mini, ça devrait suffire (sur le bouton lui-même, on touche pas à .toggle_box_link bien sûr).

  Un peu sur le même sujet, toujours dans editer_liens il y a aussi les boutons « Retirer cette patate ».
  Actuellement ça merdouille un peu car il y a des styles propres au formulaire qui se téléscopent avec la classe générique .link.
  Je pense que maintenant le générique suffit, plus besoin de styles précis sur ce bouton : avec les classes .link.mini.supprimer on a ce qu’il faut.
  Et notamment, ça permettrait d’harmoniser l’apparence entre les boutons « Ajouter une patate » et « Retirer cette patate ».
  Dans l’image-jointe il y a ce que ça donnerait avec le "avant" sur les mots-clés et le "après" sur les auteurs.
  Mais donc idéalement ça supposerait de changer ces classes dans toutes les listes patate-lies.html de la dist, et faire en sorte de garder un affichage correct pour les autres plugins.