Recherche avancée

Sur d’autres sites (6276)

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

  9 octobre 2020, par RastaPopoulos ♥

  Ça me fait penser que c’est un bug ergonomique (plutôt grave) qui est reproché depuis le début au style "totalement flat". En effet, quand les boutons on vraiment un aspect visuel de bouton = soit en 3D, soit au moins avec un ombrage, et bien même quand la couleur du bouton ressemble à la couleur du bloc où il est placé : on voit quand même le bouton et on le reconnait comme un bouton.

  Tandis qu’avec le "totalement flat", et bien ça pète complètement le concept visuel du bouton, ça ne se détache plus, et parfois c’est même moche.

  C’est bien pour ça que dans la conception "material design" de Google, même en étant moins 3D brut que les anciennes interfaces, il y a toujours le fait que les boutons doivent se détacher quelque soit leur couleur.

  Du coup ya peut-être (sûrement) une réflexion encore à avoir là-dessus.

  (Je n’ai jamais été pour le totalement flat, justement car je considère les arguments le critiquant très pertinents depuis le début.)

• Evolution #4548 : Améliorer _request et set_request pour prendre en compte les champs qui sont des...

  10 septembre 2020, par RastaPopoulos ♥

  @marcimat ? "n’a pas beaucoup de sens" ? => c’est la syntaxe officielle normalisée de HTML ! Ça a d’après moi encore plus de sens de gérer cette écriture, que de gérer une écriture personnalisée (à base de / chez nous, de . chez laravel), qui est très bien aussi et qui devrait être fait aussi d’après moi, mais qui mais nous est propre, en interne. Alors que la première écriture ne nous est pas propre : c’est la norme HTML !
  Les deux fonctions request (_request et set_request) sont directement liées aux formulaires HTML, dont la norme de nom de champ est "tableau[index]" et non pas "tableau/index", donc la priorité c’est de prendre en compte l’écriture officielle directement liée.

  Et comme je le dis plus haut, et contrairement à ce qui se discutait dans #4110 : ça n’a aucune spécificité à Saisies. On peut stocker la liste des noms des champs pour d’autres raisons, et on a aussi des squelettes à inclure et des filtres PHP dans le noyau qui génèrent des champs devant leur passer "nom" ou "name" en param (pour id_parent, pour sélectionner rubrique, article…) et qu’on peut parfaitement vouloir poster dans un sous-tableau (ya plein de raisons valables et utiles, comme éditer un objet dans un autre, une géoloc, des infos de commerce, etc, des milliers - si :p - d’autres CMS font ça depuis toujours : patate[gis][lat]… patate[prix][taxe]…).

  Quand ensuite on veut récupérer ou modifier ces valeurs postées en masse automatiquement, car on connait les noms de chacun, sans faire un traitement à la main particulier, bah ce qu’on connait c’est "patate[gis][lat]", donc autant pouvoir l’utiliser directement.

  Après si ça ne prend en compte que "tableau/index" mais que le core fournit aussi la transformation et qu’il faille écrire _request(name2chemin('patate[gis][lat]')) plutôt que directement _request('patate[gis][lat]'), ça serait déjà ça puisque ça permet l’automatisation aussi… (mais dans ce cas pourquoi ne pas l’appeler directement en interne, ça ne coûte rien du tout de plus !)

  Au niveau du code, ya rien de compliqué à gérer dans ce cas, rien de "ça va être chiant", puisque SPIP a déjà tout ce qu’il faut pour chercher une valeur suivant un "chemin". Il y a uniquement 2 choses à faire :
  - avoir une fonction mutualisée qui transforme la norme HTML en chemin de chez nous (avec / donc) et appeler cette fonction au tout début des deux fonctions request
  - dans les deux fonctions chercher table_valeur($tableau, $var) plutôt que directement $_GET[$var], $_POST[$var] etc

  Ainsi dans _request() avant c’était :
  

  if (is_array($c)) 
      return isset($c[$var]) ? $c[$var] : null ;
  
  if (isset($_GET[$var])) 
  
      $a = $_GET[$var] ;
  
   elseif (isset($_POST[$var])) 
  
      $a = $_POST[$var] ;
  
   else 
  
      return null ;
  
  
  

  Et alors ça serait environ :
  

  $chemin = name2chemin($var) ;
  if (is_array($c)) 
  
      return table_valeur($c, $chemin) ;
  
  
  
  if ($valeur=table_valeur($_GET, $chemin) !== null) 
  
      $a = $valeur ;
  
   elseif (…
  

  Quasiment rien qui change !

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

  7 octobre 2020

  cedric signalait un problème dans la liste des plugins de SVP : parfois les boutons chevauchent la case à cocher.
  Plus précisément quand un plugin n’a pas de descriptif.

  Et pour cause : les boutons sont positionnés en absolute, calés en bas à droite de chaque ligne.
  Donc depuis le début ils pouvaient chevaucher le titre et le descriptif, et maintenant qu’ils sont un peu plus grands, ça empiète parfois sur la case à cocher (plus embêtant).

  Pour régler le problème à peu de frais on peut utiliser la variante .mini sur les boutons, mais c’est un peu cacher la misère sous le tapis je trouve.
  En fait ça fait partie des problèmes d’UX évoqués dans les tickets #4429 et #3017.

  En attendant l’implémentation de la solution proposée, on pourrait déjà faire quelques ajustements :

  • Boutons visibles tout le temps, pas juste au survol
  • Boutons calés à droite, pas en absolute. On a maintenant assez de place en largeur pour ça.

  Nb : dans la capture j’ai mis les logos en 50px (au lieu de 32px), mais c’était juste pour voir.