Recherche avancée

Sur d’autres sites (12772)

• 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

  Mais pour l’ajout là c’est bizarre on voit pas le fond, c’est un peu nul, en tout cas pour cette couleur.

  Oui : https://core.spip.net/issues/4562#note-25 et https://core.spip.net/issues/4562#note-5

  Peut-être l’inverse aussi, le retrait est plus gros que l’ajout : ça ne va pas.

  Oui c’est pas voulu, la capture a été faite à l’arrache dans l’inspecteur, devait rester un font-size planqué quelque part (il y en a pleins d’imbriqués en vrac de partout). Les 2 étaient censés être à la même taille.

  Mais bref, pour mettre le bouton d’ajout à la taille normale il y a pas trop la place pour l’instant : les .toggle_box_link sont positionnés en absolute, ça ferait déborder. Et s’il faut faire rentrer tout ça je sens que ça va amener modifier pleins de choses en cascade. On tire sur un fil et on finit par dérouler toute la pelote de laine :p

  On peut y aller par étapes aussi : laisser tout en .mini.link dans un 1er temps ça me semble acceptable, histoire de garder un truc proche de ce qu’il y avait avant, mais déjà un peu plus harmonisé. Et pis après on amélioera.

• Révision 22269 : Retour sur r22264. En fait l’emplacement orginel de "interdire_scripts" provoque ...

  25 juin 2015, par esj -
  • la neutralisation inopportune des scripts introduits par le compilateur (bug corrigé par r22264) ;
    • l’altération des appels à des scripts introduits par un rédacteur, scripts q’il ne faut effectivement pas interpréter (cas du squelette nécessitant une double passe de PHP, cf. scénario possible sur http://article.gmane.org/gmane.comp.web.spip.devel/66397) mais cette stratégie brutale ne répond pas à l’intention d’un rédacteur qui s’attend à voir s’afficher le source de l’appel du script, pas le résultat de son exécution (je ne parle évidemment pas d’un rédacteur malveillant qui essaye d’exploiter une faille).

  A première vue la résolution correcte du 2e point nécessite de gros changements
  dans la stratégie de compilation adoptée depuis le début de SPIP.
  Il vaut mieux se donner le temps de la réflexion avant d’aller dans cette voie.
  Je remets le code antérieur par "svn merge -r -r22264:22263 ."
  pour ne pas laisser cette faille potentielle,
  en actant provisoirement que le premier bug doit être considéré comme une limitation de SPIP,
  savoir le fait qu’il n’est pas possible d’utiliser une balise produisant du PHP dans un argument de filtre.