Recherche avancée

Sur d’autres sites (13118)

• Evolution #4768 : Sus aux préfixes navigateurs

  5 mai 2021, par cedric -

  je suis pas fan du prefixeur JS :(

  Dans le plugin BS4 j’ai fait un mini-prefixeur utilisable en filtre, soit dans le squelette lui même en ajoutant le filtre à la fin, soit dans le head en l’utilisant en filtre sur le nom du fichier.

  Je dis "mini-prefixeur" car il a pas la prétention de traiter tous les cas, je me suis concentré sur "tous les cas utilisés dans BS4", ce qui couvre quand même les cas les plus courants... (mais pas les css grids par exemple donc)

  J’avais fait une recherche sur les prefixeurs PHP, mais rien trouvé de super convaincant. Cela dit, si quelqu’un a une lib propre et à peu près à jour sous la main, on peut facilement l’intégrer au lieu du truc à la main, et ainsi avoir donc un prefixeur PHP facile à utiliser...

• Evolution #4727 (Nouveau) : Des pictos / icônes symboliques pour tout le monde

  12 avril 2021

  Je fais un ticket pour la future PR et poser le plan d’action.
  C’est la suite de https://core.spip.net/issues/4562#Des-ic%C3%B4nes

  Proposition pour intégrer un jeu complet d’icônes symboliques.¶

  Les besoins sont multiples pour pleins d’éléments d’interface, dans le core et les plugins : des barres d’outils, des boutons d’actions, etc.
  Et chacun doit réimplémenter ça un peu à sa sauce, notamment dans le privé.

  C’est un besoin bien distinct des icônes svg de couleur dont on dispose actuellement dans le privé : on veut des pictos symboliques qui héritent de taille et de la couleur du texte, et issus d’un même set afin d’avoir un style unifié.
  Cela vient donc en complément.

  Il s’agit donc de reprendre un jeu d’icônes existant, qu’on n’aura pas à maintenir, optimisé, et qui fournit des icônes cohérentes visuellement, utilisables dans tous les contextes. Cf. plus bas pour une comparaison initiale des candidats possibles.

  Utilisation¶

  Ces icônes seraient utilisables de 2 façons :

  1) Des classes .spicon¶

  Des classes à ajouter à n’importe quel élément inline quand il s’agit d’icônes purement décoratives.
  Ces classes pouvant finir dans squelettes utilisés dans le public, pour éviter les conflits, on propose la contraption de spip + icon = spicon. Il y a aussi spip-icon mais c’est un peu plus verbeux.

  Exemples :

  <span class="CodeRay"><span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spicon_menu</span><span class="delimiter">"</span></span><span class="tag">></span>Ouvrir le menu<span class="tag"></span>
  
  <span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">spicon_truc</span><span class="delimiter">"</span></span><span class="tag">></span><span class="tag"></span> Du texte
  
  <span class="tag">span> <span class="attribute-name">class</span>=<span class="string"><span class="delimiter">"</span><span class="content">titrem spicon_machin</span><span class="delimiter">"</span></span><span class="tag">></span>Mon titre<span class="tag"></span>
  
  </span></span></span></span>

  2) Une balise #ICON¶

  En complément, on peut vouloir embarquer une icône svg dans le HTML.

  On propose de reprendre et d’adapter la balise #ICON du plugin Zcore, qui fait ça très bien.
  Cette balise permet d’embarquer une icône du set par défaut, mais également n’importe quelle autre (je rentre pas dans les détails).

  Un modèle correspondant permettra aussi d’inclure des icônes svg dans les textes :
  

  <span class="CodeRay">
  
  #ICONE{identifiant}
  
  #ICONE{chemin/vers/mon_icone.svg}
  
  #ICONE{#identifiant_autre_set}
  
  </span>

  Identifiants sémantiques¶

  Les identifiants des icônes seront directement ceux du jeu d’icônes choisi.
  Mais ils peuvent avoir des noms un peu barbares : chevron-double-right, eye-slash, grip-vertical, etc.

  Dans tous les cas on pourra les utiliser tels quels, mais en plus de ça, on propose de faire une correspondance sémantique pour les icônes correspondants aux actions les plus courantes. Par exemple au lieu de faire #ICONE{chevron-double-down} on pourra faire #ICONE{deplier}.
  Cela passerait par un pipeline, donc liste qui peut être complétée selon ses besoins.

  La liste initiale est visible ici : https://demo.hedgedoc.org/3zIXkcFLTVSwV0nKC1_qcA?both

  Ressources privé / public¶

  Cela veut dire 2 ressources à charger :

  • Une font-face pour les classes
  • Un sprite svg pour la balise

  Dans le privé, il faut charger les 2.
  Dans le public, cela pourrait se faire optionnellement, à la demande.

  Candidats¶

  Pour finir un tableau comparatif des jeux d’icônes possibles (à licences libres), avec mes commentaires initiaux.
  Petite préférence pour Feather actuellement.

  Lib	Nb	sprite	fontface	Commentaire
  Bootstrap	1300+	693ko	85ko	Clés en main, beaucoup d’icônes (trop ?)
  Feather	286	( 100ko)	-	Styles rounded. Bonne balance nb icônes / poids.
  Octicon (Github)	433	( 240ko)	-	Styles rounded. Bonne balance nb icônes / poids. Beaucoup de manips à faire pour créer sprite et cie.
  Material (Google)	?	(?ko)	44ko	Style rounded / épaisseur variable. Beaucoup de manips à faire pour créer sprite et cie. Google !
  Core-ui	554	418ko	63ko	Clés en main. Sets inutiles non pris en compte dans ce tableau (brands, flags, …)
  Bytesize	101	11ko	-	Style rounded / épaisseur variable. Léger : le minimum syndical.

  Sprite entre parenthèses = non fourni dans le dépôt ou la dist → poids théorique.

• Evolution #4753 (Nouveau) : Styles du privé : listes d’objets (suite des boîtes et des formulaires)

  30 avril 2021

  Les boîtes et les formulaires ont été visuellement « raccordés » ensembles.
  Je pense que logiquement les listes d’objets devraient suivre.
  En fait ce sont 3 variations d’un même composant : une boîte avec entête, corps et pied.

  Pour les listes on peut séparer la question en 2 aspects :

  1) L’emballage extérieur¶

  Là il s’agirait de reprendre les choix graphiques propres à « l’emballage extérieur » des boîtes et formulaires : bordure, arrondi, espacements.
  Exemple sur l’image suivant où les 3 sont visibles (nb : ceux en colonne sont automatiquement « ressérés », d’où la différence de padding etc.)

  

  Après en fonction de l’un ou de l’autre, il y aura peut-être lieu d’ajuster le padding ou la taille du titre. Mais pour l’instant ce sont ceux en place.

  2) L’intérieur¶

  Ensuite je propose de procéder à quelques ajustements à l’intérieur de ces listes.
  Je pense que certains choix ont été faits pour s’accommoder du manque de place en largeur à l’époque, et ne sont plus nécessaires maintenant.

  Pour me faire un idée de ce qui fonctionnerait le mieux, et comprendre les détails visuels qui me gênaient un peu, j’ai parcouru quelques articles de recommandations sur l’ergonomie des data tables.
  Alors ils traitent plutot des fonctionnalités de ces tables dans leur ensemble, mais il y a aussi quelques guidelines visuelles intéressantes.

  • https://uxdesign.cc/data-table-for-enterprise-ux-cb48fb9fdf1e
  • https://medium.com/nextux/design-better-data-tables-4ecc99d23356
  • https://www.uxbooth.com/articles/designing-user-friendly-data-tables/
  • https://uxdesign.cc/lets-design-data-tables-bf065a60e588

  Je retiens quelques règles simples :

  • Des espacements suffisants et consistants (le padding quoi)
  • Une taille de police identique partout (au moins dans le tbody). C’est fatiguant pour l’oeil et moins lisible quand on passe sans arrêt d’un taille de police à l’autre sur une même ligne. Et je ne suis pas sûr qu’il y ait forcément besoin de gras pour certains éléments comme les titres ou autres.
  • À quelques exceptions près (id, picto), pas de largeur fixes sur les colonnes, laisser faire le navigateur.

  Donc voilà, c’est pas grand chose à ajuster non plus.
  Les colonnes des tables ont des classes .importante et .secondaire.
  À mon avis elle ne devraient plus avoir d’incidence en vue « normale », mais juste décider quelles colonnes afficher et masquer en vue réduite, dans les colonnes ou ailleurs.

  Donc dans les grandes lignes ça donnerait quelques chose comme ça (juste une maquette) :

  

  3) Détails¶

  Enfin pour ces 3 composants, je propose qu’il y ait une classe modificatrice commune pour produire un affichage compact, c’est à dire ressérer tout le contenu.
  Cette classe serait automatiquement appliquée dans les colonnes.

  Ça pourrait être « compact », mais sur d’autres composants pour varier les tailles je suis parti sur mini / large. Donc mini aussi ?