Recherche avancée

Sur d’autres sites (6463)

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

  17 avril 2021, par RastaPopoulos ♥

  Alors c’est justement ce que je ne voulais pas générer au moins pour les groupes racines : là on se retrouve pour les fieldsets racines avec 2 bordures collées, ce qui fait super lourd visuellement il me semble : bordure du form et direct collé bordure du groupe.

  Je détaille l’argument du foncé qui était volontaire : quand il y a des décorations claires, certaines personnes (et suivant la qualité des écrans) ne les voient pas ou peu, mais ce n’est pas grave si ce n’est que de la déco. Alors qu’un élément foncé va être vu par un pourcentage bien plus grand de personnes. Comme là il s’agit d’une indication visuelle utile, et non pas juste de décoration, je trouvais donc important que ce soit foncé pour que le max de gens les voit.

  Pour les barres horizontales, là aussi c’était voulu de les enlever, afin d’alléger visuellement : là on se retrouve de nouveau avec des "cadres enfermants" de partout et donc visuellement (quand on a des yeux qui voient toutes les lignes) on a dès le premier coup d’œil cette impression de "cadres dans des cadres dans des cadres". Alors que le but des simplifications de Tcharlss était justement de minimiser le plus possible cette impression, et du coup mon but était de trouver une solution pour les fieldsets qui n’en rajoute pas dans ce domaine.

  Pour la bordure sur la droite b_b, je vais faire un essai, mais le premier truc qui me vient c’est que justement on lit à gauche, et que seulement une indentation sans bordure à gauche c’est beauuuucoup plus faible pour voir du premier coup quels champs sont regroupés avec quels autres. Ça va faire qu’on va voir le regroupement que dans un deuxième temps au lieu de le voir au début de chaque ligne.

• Anomalie #3978 : Reload ajax et contexte au retour d’un URL_ACTION_AUTEUR

  29 septembre 2018, par cedric -

  Pas de bug ici, juste une erreur de conception dans les 2 squelettes :)

  Dans le cas 1 les arguments reloada=1 et reloadb=1 sont passés en argument du href et viennent dans l’URL après un reload ajax d’un bloc
  Du coup quand on passe un {args:{reloadb:''}} et {args:{reloada:''}} dans le refresh ajax ça annule bien l’argument de l’URL et évite la boucle infinie

  Dans le cas 2 les reloada et reloadb ne sont pas en arguments de l’URL mais en argument de l’URL de retour passée à l’action
  Du coup les arguments {args:{reloadb:''}} et {args:{reloada:''}} ne viennent rien faire car ils s’appliquent sur l’URL de l’action, pas sur l’URL de retour.

  Consequence sans doute pas vue : au second coup le refresh de A se fait via l’URL action, c’est a dire en faisant une action indésirable au lieu de simplement rafraichir

  Solution : indiquer dans le refresh ajax qu’il faut utiliser l’URL de départ et pas l’URL action :

  Bloc A (#REM
  
  
      Reload A => Declenchera ensuite le Reload de B
  
  
  [(#ENVreloada|oui)
  &lt;script type=&quot;text/javascript&quot;&gt;<br />
  
      ajaxReload('blocb', {args:{reloadb:''},href:'#SELF'});<br />
  
  &lt;/script&gt;
  ]
  

  Bloc B (#REM
  
  
      Reload B => Declenchera ensuite le Reload de A
  
  
  [(#ENVreloadb|oui)
  &lt;script type=&quot;text/javascript&quot;&gt;<br />
  
      ajaxReload('bloca', {args:{reloadb:''},href:'#SELF'});<br />
  
  &lt;/script&gt;
  ]
  

  A noter qu’ici j’ai aussi ajouté une class nohistory sur les liens pour ne pas modifier l’URL de la page web et éviter qu’elle ne devienne celle de l’action

• nomenclature #3469 (Nouveau) : Étendre la balise #URL_PAGE à tout objet éditorial

  6 juin 2015, par tetue tetue

  La balise #URL_PAGE affiche actuellement la page fabriquée par le squelette passé en paramètre : http://www.spip.net/fr_article4630.html

  Cette balise pourrait être étendue aux objets éditoriaux de SPIP, de façon à être utilisée facilement, sans paramètre, pour lier explicitement la page SPIP, ce qui est utile pour les objets possédant par ailleurs une URL qui leur est propre, tel que les sites.

  #URL_PAGE afficherait l’url de la page dédiée à l’objet, c’est-à-dire la page générée via le squelette homonyme (sans nécessiter de le passer en paramètre), si ce skel existe, sinon rien.

  Par exemple :

  - dans une boucle SITES, #URL_PAGE afficherait l’url de la page fabriquée par le skel « site » — au lieu de l’actuel [(#ID_SYNDIC|generer_url_entitesite)] anciennement (#ID_SYNDIC, trop barbare — tandis que #URL_FORUM affiche l’url de la page où est affiché le message
  - dans une boucle DOCUMENTS, #URL_PAGE afficherait l’url de la page fabriquée par le skel « document », s’il existe, tandis que #URL_DOCUMENT affiche l’url du fichier multimédia
  - idem avec les FORUMS
  - dans une boucle SYNDIC_ARTICLES, #URL_PAGE n’afficherait rien, car le squelette « article_syndic » n’existe pas
  - dans une boucle ARTICLES, #URL_PAGE afficherait l’url de la page fabriquée par le skel « article », comme #URL_ARTICLE
  - etc.

  Il ne s’agit pas tant qu’une évolution, puisque l’affichage de toutes ces URLs est déjà possible, que d’une homogénéisation et simplification de la nomenclature. Mieux vaut écrire #URL_PAGE que [(#ID_SYNDIC|generer_url_entitesite)], n’est-ce pas ;)