Recherche avancée

Sur d’autres sites (6158)

• Evolution #4595 : [Charte privé] Soulignement des liens

  2 novembre 2020, par RastaPopoulos ♥

  Alors oui en accessibilité c’est un des tous tous premiers trucs : ne pas se reposer sur la couleur pour une info, et là c’est pas une petite info : les liens sont, genre… l’élément le plus important de navigation et d’interaction dans une page web, donc si ya un truc à pas rater niveau accessibilité et affordance, c’est bien sur cet élément.

  La règle de base devrait donc être : faut souligner ou autre méthode, mais souligner c’est vraiment le standard, et de nos jours on peut faire des soulignements assez jolis.

  Mais… si ya "de base" dans la phrase, ce n’est pas pour rien. C’est le défaut. Mais suivant tel ou tel contexte, on peut parfaitement styler autrement, car ergonomiquement on sait que telle zone de la page correspond uniquement à une liste de liens. Typiquement un menu parfaitement identifié oui. Ça vaut pour le menu principal en premier lieu bien sûr. Mais aussi pour les colonnes de côtés, dans la plupart des cas on sait ce que sont des listes de liens (comme les liens et boutons qu’on met sous le numéro des objets).

  Là où c’est le plus important de garder le soulignement c’est quand dans un même contexte il y a du texte normal et des liens mélangés. Ça vaut pour les contenus longs évidemment. Mais ça peut valoir dans certains blocs d’infos, de liaisons, tableaux d’infos etc : là il faut savoir ce qui est cliquable sans mettre la souris dessus et donc laisser le défaut il me semble.

• Anomalie #3630 : Logo d’auteur et fonction de recherche de logo

  13 août 2016, par b b

  Je dépose ici la discussion qui a eu lieu à ce sujet sur IRC pour en garder une trace :

  < marcimat‎ >  dans id_table_objet() je vois que ça fait un traitement même si on passe ’id_auteur’
  < marcimat‎ >  du coup, je me dis que quête logo
  < marcimat‎ >  pourrait tester si substr($type, 0, 3) !== ’id_’
  < marcimat‎ >  appeler id_table_objet($type)
  < marcimat‎ >  non ?
  < marcimat‎ >  c’est peut être un compromis
  < marcimat‎ >  ou un strcmp
  < phenix_spip‎ >  Pourquoi faire un test ?
  < marcimat‎ >  parce que je vois des calculs dans id_table_objet() systématiques
  < marcimat‎ >  même si on envoie déjà id_truc
  < phenix_spip‎ > ?
  < phenix_spip‎ >  Ha je vois
  < marcimat‎ >  @id_table_objet()
  < Edgard‎ >  Hop http://code.spip.net/@id_table_objet - Hop (sinon) http://code.spip.net/spip.php?page=recherche&recherche=id_table_objet
  < marcimat‎ >  https://core.spip.net/projects/spip/repository/entry/spip/ecrire/base/objets.php#L1066 donc
  < marcimat‎ >  mais effectivement, je pense que ça doit pas gêner si quête_logo est simplifié
  < phenix_spip‎ >  marcimat : ce serai plus logique que le test soit dans id_table_objet non ?
  < marcimat‎ >  enfin modifié pour accepter un vrai type
  < marcimat‎ >  certes, mais c’est déjà plus sensible ^^
  < phenix_spip‎ > ?
  < marcimat‎ >  ok
  < marcimat‎ >  en fait objet_type() teste déjà en enlevant id_
  < marcimat‎ >  donc, y pa pas spécialement besoin
  < phenix_spip‎ >  Ben voilà :)
  < marcimat‎ >  donc là https://core.spip.net/projects/spip/repository/entry/spip/ecrire/base/objets.php#L1070
  < marcimat‎ >  objet_type(’id_auteur’) doit ressortir ’auteur’
  < marcimat‎ >  oui, voilà :)
  < marcimat‎ >  all is fine
  

• Anomalie #3164 : Problème de sauvegarde en MySQL

  7 février 2014, par Franck Dalot

  En spip 2.1, avec comme prefix des table spipdev et avec uniquement dans mes_options :
  

  <?php
$table_prefix = 'spipdev';
?>

  Cela ne fait apparaitre dans la liste que des tables qui porteraient le nom de spip_xxx ET cela fait les sauvegardes avec le prefix spip_xxx au lieu de spipdev_xxx
  Et cela manque toujours des tables, puisqu’il n’y a de cocher que :
  spip_articles (0)
  spip_auteurs (2)
  spip_auteurs_articles (0)
  spip_auteurs_messages (0)
  spip_auteurs_rubriques (0)
  spip_breves (0)
  spip_documents (0)
  spip_documents_liens (0)
  spip_forum (0)
  spip_groupes_mots (0)
  spip_messages (0)
  spip_meta (91)
  spip_mots (0)
  spip_mots_articles (0)
  spip_mots_breves (0)
  spip_mots_documents (0)
  spip_mots_forum (0)
  spip_mots_rubriques (0)
  spip_mots_syndic (0)
  spip_petitions (0)
  spip_referers (0)
  spip_referers_articles (0)
  spip_resultats (0)
  spip_rubriques (0)
  spip_signatures (0)
  spip_syndic (0)
  spip_syndic_articles (0)
  spip_types_documents (164)
  spip_urls (0)
  spip_versions (0)
  spip_versions_fragments (0)
  spip_visites (0)
  spip_visites_articles (0)

  Alors que logiquement, il devrait y avoir :
  spipdev_articles (0)
  spipdev_auteurs (2)
  spipdev_auteurs_articles (0)
  spipdev_auteurs_messages (0)
  spipdev_auteurs_rubriques (0)
  spipdev_breves (0)
  spipdev_documents (0)
  spipdev_documents_liens (0)
  spipdev_forum (0)
  spipdev_groupes_mots (0)
  spipdev_messages (0)
  spipdev_meta (91)
  spipdev_mots (0)
  spipdev_mots_articles (0)
  spipdev_mots_breves (0)
  spipdev_mots_documents (0)
  spipdev_mots_forum (0)
  spipdev_mots_rubriques (0)
  spipdev_mots_syndic (0)
  spipdev_petitions (0)
  spipdev_referers (0)
  spipdev_referers_articles (0)
  spipdev_resultats (0)
  spipdev_rubriques (0)
  spipdev_signatures (0)
  spipdev_syndic (0)
  spipdev_syndic_articles (0)
  spipdev_types_documents (164)
  spipdev_urls (0)
  spipdev_versions (0)
  spipdev_versions_fragments (0)
  spipdev_visites (0)
  spipdev_visites_articles (0)

  Sans fichiers mes_options mais en changeant la ligne 320 par
  

  . preg_replace(',^spip_,', $GLOBALS['table_prefix'].'_', $t)

  
  c’est pareil que si l’on ne changeait pas la ligne.
  Les tables apparaissent en double et ne sont cocher que 26 tables spip_xxx alors qu’il devrait y avoir 33 tables et en plus avec le prefix choisi au moment de l’instal

  En spip 3.1, même avec
  

  
<?php
$table_prefix = 'spipdev';
?>

  
  Cela ne sauvegarde pas les tables avec un autre prefix que spip_XXX