Evolution #4468
Unification des CSS pour les boutons et les icônes
0%
Description
Dans la colonne gauche du privé, les boutons et liens sont stylés de manière très hétérogène
- certains sur fond de la couleur choisie par l'utilisateur, certains sur fond grisé
- parfois en pleine largeur, parfois pas
- parfois alignés à gauche, parfois centrés, parfois alignés à droite
Voir la copie d'écran où les boutons du plugin Duplicator pâtissent singulièrement de cette lacune dans les css, mais où on voit aussi les divergences des autres composants au dessus et en dessous
Associated revisions
Ticket #4468 : unifier styles des icônes (classe .icone), boutons d'actions et boutons de validation des formulaires. Même police, graisse et couleurs pour tous. Portage des classes .add, .del, .edit et.config qui ajoutent des icônes aux boutons d'actions, ainsi que de .link, .right et .left. Ajout également de nouvelles classes modificatrices à toute fin utile : .secondary, .block, et .boutons_groupe. Testé en ltr et rtl. Une page d'exemple temporaire dispo sur exec=issue_4468 avec toutes les classes et combinaisons possibles.
#4468 : ajout d'une variante .principal, renommer .secondary en .secondaire, .block en .bloc, padding plus petit + le laisser en partie sur la variante .link
History
#1
Updated by RastaPopoulos ♥ 11 months ago
Alors plusieurs choses mélangées :
- tu confonds les liens et les boutons (des formulaires donc)
- je ne sais pas quelle version de Duplicator tu as, mais à priori pas la dernière, vu que l'intitulé est "Dupliquer ce contenu et ses enfants"
- les boutons sont toujours en text-align center, même SPIP ne fait rien sur ça, ce sont les styles de nav par défaut
- je ne sais pas pourquoi tu as l'un des boutons large et l'autre pas, normalement ils sont juste en inline, donc largeur suivant le contenu, et non pas 100%
#2
Updated by jluc - 11 months ago
Le sujet c'est l'apparence, qui est hétérogène et bancale...
J'ai bien la dernière version de duplicator mais oups j'avais édité le texte du lien avant le copie d'écran, pour voir si c'était mieux quand le texte tenait sur une seule ligne.
Cependant ça ne change rien à l'apparence hétérogène.
#7
Updated by RastaPopoulos ♥ 11 months ago
C'est totalement faux et l'inverse : il faut absolument distinguer lien et bouton, car les liens ne font rien, ils amènent à un autre endroit. Tandis que les boutons modifient des choses dans la base de données, ce qui n'a strictement rien à voir. C'est la base de l'affordance de la différence entre les deux, ça ne doit surtout pas être amalgamé !
#9
Updated by tcharlss 🐽 11 months ago
Le ticket a au moins ce mérite : je viens enfin de saisir d'où sortent ces pseudo-boutons sur fond gris :D
C'est quand on active l'option « afficher uniquement le texte » dans les préférences utilisateurs. Le truc que j'ai du tester une fois il y a 10 ans et que j'avais complètement oublié depuis.
#URL_TRUC|icone_horizontale{...}
#BOUTON_ACTION
(Des fois on a direct des #URL_ACTION_AUTEUR
mais c'est mal :p)
Et si je suis d'accord qu'il faut bien distinguer visuellement les boutons de formulaires et les simples liens, il y a des choses à harmoniser, ça fait un peu disparate dans l'ensemble.
Et +1 pour changer le titre du ticket
#10
Updated by RastaPopoulos ♥ 11 months ago
Je ne tempère rien du tout : si c'est un lien c'est une faute importante, et absolument aucune suppression dans la base ne doit se faire avec un lien HTML, balise <a>. Donc c'est un bug dans le code du noyau de SPIP, et donc sans rapport avec ce ticket.
Une fois que les bonnes balises sont utilisées suivant les comportements voulus (= un lien pour amener quelque part, et un bouton pour modifier la base), et bien je le répète, les liens et les boutons ne devraient pas être confondues, ce sont des actions totalement différentes. Quand un utilisateur a la vision d'un lien, il sait que ça va juste "changer sa vue", soit en l'amenant sur une autre page, soit en rechargeant un morceau de la page en cours (ajax ou ancre peu importe). Quand un utilisateur voit un bouton, il sait que ça va modifier quelque chose, ça va faire une action, ce n'est pas juste un changement de vue.
Les deux seules exceptions les plus courantes (dans tout il y a des exceptions, mais ça reste rare, ça ne veut pas dire qu'il n'y a pas une règle de base) :
- faire qu'un lien ait l'apparence d'un bouton si c'est un lien qui amène à une vue qui permet de modifier des choses, donc c'est comme si ce lien était la première étape de l'action (mais c'est bien un lien qui amène à changer de vue, ce n'est surtout pas un lien qui modifie directement quelque chose !)
- faire qu'un bouton ait l'apparence d'un lien, pour annuler une action, car il s'agit effectivement d'une non-action, de revenir au départ, à la vue de départ
Mais tout cela implique bien que les liens et boutons doivent absolument continuer d'être différenciés (colonne de gauche ou pas, n'importe où), et ces deux exceptions sont rares et réfléchies.
#11
Updated by tcharlss 🐽 11 months ago
- File 4468.png View added
- File 4468_pref.png View added
#12
Updated by tcharlss 🐽 11 months ago
Pour illustrer, voici ce qu'on obtient selon la préférence utilisateur :
Texte + icône (le défaut)
Texte uniquement
- Des fois on a une bordure, des fois non
- Des fois les coins sont arrondis, des fois non
- Des fois c'est en dispay: block et ça prend toute la largeur, des fois non
Et quand on veut afficher un bouton d'action comme un lien, la taille du texte est plus petite.
Et je pense aussi que c'est pas rare que les gens utilisent |icone_horizontale au lieu de #BOUTON_ACTION uniquement pour avoir un bouton "plus joli", ou disons plus sémantique visuellement (comme avec le paramètre "del" qui ajoute un fond hachuré).
#13
Updated by tcharlss 🐽 11 months ago
- File 4468_apres.png View added
- File 4468_avant.png View added
#14
Updated by tcharlss 🐽 11 months ago
Petite proposition pour unifier un peu les liens icônes et les boutons d'actions :
- Police identique : taille, couleur, graisse
- Ajouter la prise en charge des classes del, add et edit pour les boutons d'actions :
[(#BOUTON_ACTION{Glop,#URL,add})]
Ce qui donnerait ça :
Et comme c'est actuellement pour référence :
Et aussi : la préférence pour afficher le texte uniquement devrait juste enlever les icônes, sans autre différence de style
#15
Updated by tcharlss 🐽 11 months ago
- File 4468_apres2.png View added
#16
Updated by tcharlss 🐽 11 months ago
Et même à la réflexion, pour les boutons d'actions prendre un gris neutre au lieu de la couleur utilisateur (qui pique un peu les yeux des fois), pleine largeur et centrer le texte (si dans une colonne).
#17
Updated by nicod _ 11 months ago
- File 4468_apres3.png View added
Ça me parait pas mal du tout, j'y mettrais un tout petit poil plus de border-radius pour les adoucir, et le même espacement vertical sur les liens que sur les boutons.
Peut être l'occasion aussi de changer l'icone "del" ? ça fait longtemps que je me dis qu'on dirait plutôt un panneau "sens interdit".
#19
Updated by jluc - 11 months ago
Merci Rasta pour les explications. Désolé je suis pas expert mais ouf j'ai échappé à tes majuscules.
En regardant sur un autre SPIP je vois qu'il n'y a pas autant de différences donc certains pb viennent de mes propres css. Les boutons sont à droite sauf ceux de Duplicator et celui pour supprimer le logo (centré).
Les boutons de Duplicator sont auto-forms, alors ça justifie peut être un traitement particulier, mais plutôt qu'alignés à gauche, je les préférerais texte-centrés à width-100% de la colonne comme ceux présentés par Tcharlss ou nicod_.
Et le bouton pour supprimer le logo est tellement associé à l'image qu'il gagnerait à être remplacé par une simple croix dans un coin du logo, non ? Comme ça il n'y aurait plus ce centrage exceptionnel.
Les changements proposés sont chouettes aussi.
Et une simple croix en X rouge pour "Del" ? Ça serait plus léger non ?
Et pourquoi pas aussi un simple plus + vert pour "Add" plutôt qu'un + blanc sur fond rond vert ?
#20
Updated by nicod _ 11 months ago
- File icone-del.png View added
Je ne suis pas expert UI/UX, mais pour les icônes, je trouve qu'un symbole simple (une croix ou un plus) est plus lisible quand il est contenu dans une forme, il se distingue mieux du texte.
Au passage ce crayon n'est pas hyper lisible non plus à première vue, mais j'ai pas mieux.
Au cas où, ci joint l'icone "del" en bonne résolution.
#22
Updated by tcharlss 🐽 11 months ago
Ok pour le PR avec le border-radius et la marge.
Pour l'icône je pense qu'il vaut mieux traiter ça à part dans un autre PR, en fait ça ouvre la porte à d'autres questions.
Est-ce que cette icône doit forcément signifier qu'on supprime un contenu ? Elle pourrait être aussi utilisée pour des boutons d'action qui dissocient des contenus par ex., sans les supprimer.
L'icône actuelle a le mérite d'être assez générique sur ce point, elle peut être utilisée dans un cas ou dans l'autre.
Sinon ça voudrait dire compléter les icônes et les classes qui vont avec pour distinguer plusieurs types d'actions :
- supprimer
- retirer ou dissocier
- annuler
- ...
#23
Updated by tcharlss 🐽 11 months ago
- File 4468_v2.png View added
- File 4468_v2_avant.png View added
#24
Updated by tcharlss 🐽 11 months ago
C'est dans la branche de test issue_4468 : https://git.spip.net/spip/spip/src/branch/issue_4468
Se rendre sur ?exec=issue_4468 pour voir en vrai
Bon, c'était comme d'habitude un peu pus compliqué que ce qu'il n'y paraissait, et faut s'y retrouver dans ces CSS minifiées...
En résumé :
- Typo des icônes, boutons d'action et boutons de formulaires unifiées (couleur, police, graisse).
- Boutons d'actions et de formulaires unifiés aussi (padding, border-radius, couleur de fond)
- Portage des classes
add, del, edit, config
aux boutons d'actions, qui reprennent les icônes de la classe .icone - Portage des des classes
left, right
aux boutons d'actions (et correction de .icone.right qui merdait)
Ça c'était pour la partie "porter certaines classes des icônes sur les boutons d'action et unifier les styles".
Tant qu'à faire, j'ai aussi ajouté une poignée de nouvelles classes génériques pour les boutons d'actions ou de formulaires (utilisées nulle part pour l'instant donc, mais dispos si besoin) :
secondary
pour les boutons secondairesblock
pour mettre un bouton en pleine largeur (automatique pour les boutons en colonne latérale)boutons_groupe
pour encapsuler une séries de boutons adjacents.
En image :
Et l'actuel pour comparaison :
#25
Updated by nicod _ 11 months ago
Pas mal du tout, avec ces nouvelles classes.
Mais tu as ajouté du padding sur les boutons par rapport à 4468_apres2.png, ils paraissent peut être un poil gros non ?
Et je me demande si le gris est bien la bonne couleur pour un bouton d'action, mais bon, on n'a pas non plus des masses de choix.
En tout cas, avec les deux vues côte à côte, ça rafraichit bien :)
#26
Updated by tcharlss 🐽 11 months ago
Possible qu'il y ait plus de padding, la 1ère capture c'était sur des modifs faites à l'arrache dans l'inspecteur de firefox, j'ai pas refait du pixel perfect. Mais ouais on peut baisser je pense.
Quant au gris par rapport à la couleur utilisateur, c'est pour 2 raisons :- Elle est déjà beaucoup utilisée un peu partout (bordures, fonds, etc.), c'est pour neutraliser un peu justement
- Et surtout, les icônes deviennent moins lisibles quand il y a une couleur trop saturée ou pas assez claire en fond.
Si tu veux corriger des trucs, hésite pas.
Je précise : il y a un peu de flex d'ajouté, je n'ai pas encore mis les préfixes navigateurs ni fait de fallback pour ceux qui supportent pas flex du tout (ah la plaie :p).
#27
Updated by RastaPopoulos ♥ 11 months ago
Super, peut-être une variante "important" qui justement là prend la couleur principale ? Amélioration mais comme il y a déjà quelques ajouts…
#28
Updated by marcimat 🌻 11 months ago
Ça semble sympa.
Ça pourrait pas être renommé le "boutons_groupe" en anglais (le reste des classes de cette catégorie est en anglais ; ça fait bizarre, même le .block que tu ajoutes...)
#30
Updated by tcharlss 🐽 11 months ago
RastaPopoulos :
peut-être une variante "important" qui justement là prend la couleur principale ?
Oui tant qu'à faire
marcimat :
Ça pourrait pas être renommé le "boutons_groupe" en anglais (le reste des classes de cette catégorie est en anglais ; ça fait bizarre, même le .block que tu ajoutes...)
Heu, du coup j'ai pas compris, tu suggères de tout mettre en français ou en anglais ?
L'un ou l'autre pourquoi pas, avec le mélange actuel on sait pas trop sur quel pied danser quand on arrive après pour ajouter des trucs.
Le .boutons_groupe
à la place de .button-group
c'était pour que ça soit cohérent quand c'est utilisé dans les formulaires :<div class="boutons boutons_groupe"><input class="submit" ...></div>
Le .block
c'est un peu pareil : c'est une classe qu'on peut passer en paramètre de |icone_horizontale
et de #BOUTON_ACTION
, et là actuellement c'est que des termes anglais (add, link, etc.)
C'est pas simple cette histoire...
b b :
faut s'y retrouver dans ces CSS minifiées
Pour info c'est débrayable avec define('_INTERDIRE_COMPACTE_HEAD_ECRIRE',true); ;)
Ah mais je parlais de l'écriture avec toutes les règles sur une ligne et sans espace dans les CSS :.classe{truc:machin;chose:bidule;pouet:truc;}
J'ai perdu un dizième à chaque oeil à tout relire :p
#31
Updated by nicod _ 11 months ago
tcharlss 🐽 a écrit :
RastaPopoulos :
peut-être une variante "important" qui justement là prend la couleur principale ?Oui tant qu'à faire
Je dirais plutôt "primaire" (dans le sens couleur primaire mais bof) ou "principal", ou qqchose comme ça, plutôt que 'important".
Ah mais je parlais de l'écriture avec toutes les règles sur une ligne et sans espace dans les CSS :
.classe{truc:machin;chose:bidule;pouet:truc;}
J'ai perdu un dizième à chaque oeil à tout relire :p
Pareil, à chaque fois :)
Je proposerais bien de passer un coup de formatage sur tous ces fichiers, franchement, ça ferait pas de mal.
PhpStorm fait ça très bien.
#32
Updated by b b 11 months ago
- Status changed from Nouveau to En cours
Perso je colle toujours tout sur une ligne pour les règles, et chaque sélecteur sur une ligne différente, chacun ses préférences, mais je complètement d'accord avec vous sur le manque d'espace dans les déclarations des règles, j'ai tendance à les corriger dès que je modifie ou ajoute un nouvel élément pour espacer comme ça { display: inline-block; border: 0; }
. On devrait en parler dans un ticket dédié, il faut qu'on se fixe des règles sur ce point comme on l'a déjà fait pour les PSRs.
#33
Updated by tcharlss 🐽 11 months ago
On devrait en parler dans un ticket dédié, il faut qu'on se fixe des règles sur ce point comme on l'a déjà fait pour les PSRs.
+1 (et on avait évoqué aussi la question pour les squelettes d'ailleurs, à un moment.)
Je crois que le plus simple c'est de choisir une convention qui corresponde à ce que font les formateurs (ou linters, ou beautifiers, bref...). Comme ça on peut faire le truc automatiquement sans se prendre la tête.
Et la convention dans tous les formateurs que j'ai testés, c'est plutôt une règle par ligne.
Dans certains guides ou articles de blog, on trouve parfois des gens qui regroupent des familles de règles par ligne (positionnement, police, etc.), mais bon, le mieux c'est de rester sur des conventions simples à se rappeler amha.
#34
Updated by tcharlss 🐽 11 months ago
Je proposerais bien de passer un coup de formatage sur tous ces fichiers, franchement, ça ferait pas de mal.
PhpStorm fait ça très bien.
+1
Mais alors peut-être après si cette prop abouti à un PR, sinon j'ose pas imaginer la galère pour merger :p
#35
Updated by tcharlss 🐽 11 months ago
- Ajouté une variante .principal (comme ça on a principal / secondaire)
- Renommé .secondary en .secondaire
- Renommé .block en .bloc
- Réduit le padding (+ remis sur les .link)
Comme ça toutes les nouvelles classes sont en français.
Ah les nouvelles classes, ce ne sont que des propositions. S'il n'y a aucun cas concret d'utilisation possible dans le privé (les groupes de boutons par ex.), ça peut être viré.
Bon j'arrête les captures, à voir sur ?exec=issue_4468
#36
Updated by b b 11 months ago
tcharlss 🐽 a écrit :
Et la convention dans tous les formateurs que j'ai testés, c'est plutôt une règle par ligne.
Tututu, de mon côté j'utilise https://github.com/fidian/PrettyCSS/ qui me permet d'utiliser la convention pour laquelle j'ai une préférence avec cette config https://gist.github.com/brunob/d16beef0f181a55e24b5 ; tous ces outils sont configurables à souhait ;)
#37
Updated by RastaPopoulos ♥ 11 months ago
Non mais cherche pas, tout sur la même ligne c'est IMMONDE et ILLISIBLE (15 règles sur la même ligne, super pour retrouver TELLE règle précise cachée tout à droite en scroll horizontal). Aucun framework ne fait ça pour maintenir le code à plusieurs sur le long terme.
(saurez vous trouver l'auto caricature dans ce message) :p
#39
Updated by PIerre LASZCZAK 6 months ago
Hello,
Est il possible de prévoir une class pour habiller les liens en boutons.
Quelque suggestions de markup que j'ai l'habitude d'utiliser:
a .bouton ou a .button (apparence d'un bouton de spip couleur neutre gris?)
a .bouton.theme ( couleur du theme claire)
a .bouton.theme.foncee (couleur du theme foncee avec en prime du blanc couleur texte blanc?)
possiblement ajouter une classe hover
a .bouton.theme.hover-foncee ( couleur theme clair avec un effet hover: backgound fonce et texte blanc?)
Merci tcharlss :)
#41
Updated by tcharlss 🐽 5 months ago
- File 4468_bouton_action_icone_1.png View added
- File 4468_bouton_action_icone_2.png View added
Noté pour ajouter un a.bouton
Il y a déjà des variantes .principal et .secondaire dans cette prop, donc il suffit de les reprendre (cf. captures et description messages précédents).
Par contre la classe .bouton est déjà utilisée dans le bandeau d'ajout rapide : <ul class="rapides_creer"><li class="bouton">
.
Donc pour les liens boutons, il faudrait soit limiter à la balise <a>
→ a.bouton { … }
, mais c'est un peu sale. Ou alors trouver une autre classe pour le bandeau.
Un dernier truc à régler aussi : dans les styles actuels il semble être prévu de pouvoir utiliser les classes .icone.horizontale sur les boutons d'action, c.à.d #BOUTON_ACTION{…, …, …, icone horizontale s-24}
.
Mais je n'arrive pas à voir quel résultat est censé être obtenu avec cette combinaison. Actuellement, ça à l'air pété, cf. captures.
D'une part ça n'est mentionné nulle part dans la charte (du plugin dev), et de l'autre ça semble n'être utilisé qu'une seule fois dans la dist, dans la page controler_urls. Ailleurs je n'ai vu ça utilisé que dans la Fabrique (les boutons de suppression d'objet).
Je suppose que le but c'était d'essayer d'afficher un bouton d'action comme une |icone_horizontale
.
Mais |icone_horizontale
ça produit un markup très différent de #BOUTON_ACTION
, essayer de finir de porter la classe .icone.horizontale sur ce dernier ça va être bien compliqué.
Mais en fait dans cette prop, on peut déjà avoir des icônes facilement dans les boutons d'action, soit en utilisant une des variantes new, add, del, config, ou alors en mettant une image/icône à la main dans le label tout bêtement.
Donc au final ça me semble plus simple d'arrêter de supporter la combinaison #BOUTON_ACTION
+ classe .icone : en l'état ça marche à moitié, c'est inutile avec cette prop, et ça fait un truc compliqué en moins à maintenir.
#42
Updated by tcharlss 🐽 5 months ago
@jluc : pretty please, c'est possible de renommer ce ticket en quelque chose de plus approprié ? Le sujet a glissé plus précisément sur les boutons et les icônes de la charte du privé. Meurchi.
#43
Updated by tcharlss 🐽 5 months ago
Ah et dernière question pour les sachant⋅e⋅s : est-ce que quelqu'un⋅e peut m'expliquer vite fait la logique du découpage des squelettes css du privé ?
Je vois qu'il y a un fichier général theme.css.html un peu fourre-tout, et quelques fichiers pour des modules précis : forms.css.html, icons.css.html, etc.
Donc la logique semble être : les trucs qui correspondent à un module précis sont dans un fichier css.html à part, et tout le reste en vrac dans theme.css.html.
Sauf que parfois un module a des règles à la fois dans le fichier général et dans le fichier dédié. Et parfois les mêmes règles. Par exemple pour les formulaires, il y en a un bout dans theme.css.html et aussi dans forms.css.html.
En l'état, quand il y a des modifs à faire c'est le doutage, on les fait où ?
Là comme il s'agit de mutualiser les styles de plusieurs choses, dont les boutons de formulaire, le mieux serait de déplacer tout ce qui concerne les boutons dans un nouveau module boutons.css.html tout simplement, depuis forms.css.html et theme.css.html.
Des objections ?
#44
Updated by RastaPopoulos ♥ 5 months ago
Je dirais : ya sûrement eu une bonne volonté de rangement, mais comme dans plein d'autres endroits de SPIP, c'est pas carré cohérent, avec encore du bazar pas rangé.
+1 pour déplacer les styles de boutons dans un module dédié (et ranger tous les trucs de forms dans le module de forms, s'il en reste en bazar ailleurs)
#46
Updated by nicod _ 5 months ago
Donc pour les liens boutons, il faudrait soit limiter à la balise <a> → a.bouton { … }, mais c'est un peu sale. Ou alors trouver une autre classe pour le bandeau.
Pourquoi "un peu sale" ? à part a
et button
, voir input[type=button]
je ne vois pas où on pourrait appliquer cette classe.
Mais +1 pour renommer la classe des li
de <ul class="rapides_creer"><li class="bouton">
, qui n'a pas de logique là, ce serait plus cohérent.
#48
Updated by tcharlss 🐽 5 months ago
@b_b : Super, merci
@jluc : Ah je pensais qu'on pouvait au moins éditer ses propres tickets sur trac, même sans être admin. Je viens de voir que j'aurais pu le faire moi-même d'ailleurs, mais je me suis encore fait avoir par l'UX : faut d'abord cliquer sur modifier, et ensuite sur la petite icône « changer la description ». Mon cerveau refuse de retenir ce truc.
Alors en fin de compte j'ai fait en sorte de ranger un minimum, mais en essayant de pas toucher à trop de choses non plus :
- Tout ce qui a trait aux boutons est dans un nouveau module boutons.css : les boutons de formulaires, les boutons d'action, et la nouvelle classe lambda .bouton.
- Je n'ai pas touché au bando rapide, donc pour les nouveaux boutons le sélecteur CSS inclus le tag : a.bouton. Je disais que c'est sale parcequ'en dehors des règles de base (reset, typo…), la règle générale c'est d'éviter de cibler un tag en particulier.
En parlant de rangement, le module icons.css contient aussi les onglets (barre + onglets simples). À mon avis le composant .icone.horizontale|verticale ça rentre dans la famille des boutons, donc à déplacer dans le module boutons.css, et le module icons pourrait ensuite être renommé en onglets.css.
Mais bon, j'y touche pas, ça pourra faire l'objet d'un autre ticket spécifiquement pour le découpage et le rangement des modules.
Je vais essayer de boucler ça demain, y a moyen de faire un PR pour tenter de squeezer ça dans l'alpha de la 3.3 amha.
J'y mettrai un description complète de la prop incluant les derniers correctifs.
#50
Updated by tcharlss 🐽 5 months ago
- File 4468_v3_apres_demo.png View added
Hop, point étape avant de lancer un PR.
Ça me semble prêt, mais il y a peut-être quelques derniers retours à faire ici avant soumettre un PR.
Surtout des tests à faire pour voir si tout est ok.
Donc les dernières suggestions ont été intégrées, cf. commit : https://git.spip.net/spip/spip/commit/47a4a2cd.
Quelques remarques techniques :
- J'en ai profité pour prendre en compte le reste des icônes svg correspondant à des actions génériques, donc en complément de add, new et cie : export, import, ouvrir et fermer.
- Maintenant que les icônes sont en svg il n'est plus nécessaire que les images elles-mêmes soient décalées (c'est à dire que le "+" soit en bas à droite par ex.), ça compliquait beaucoup les choses pour les réutiliser ailleurs. Donc je les ai recadrées. Pas touché aux versions png mais à priori elles ne sont plus utilisées.
- J'ai aussi mis quelques animations au survol des icônes. Bon là j'ai pas encore assez de recul pour voir si c'est pas trop distrayant à l'usage. Mais j'aime bien le petit effet bling.
Pour voir à quoi ça ressemble, j'invite à tester la branche pour voir ce que ça donne en vrai.
Il y a une page temporaire ecrire?exec=boutons qui montre tous les cas d'utilisations possibles, avec toutes les variantes.
Attention cette page montrant tout en vrac, elle donne une fausse impression de "bariolé".
Mais en vrai, dans le reste de l'espace privé les modifs sont beaucoup moins notables.
Il ne s'agit pas d'inviter les gens à mettre des icônes à tout bout de champ dans les boutons, mais de donner la possibilité quand il y a besoin avec une bonne raison.
Sinon pour se faire une idée vite fait, il y a l'image ci dessous, et j'ai fait aussi un rapide screencast : https://medias.spip.net/medias/video-tutorials/article/ticket-4468-1
#51
Updated by tcharlss 🐽 5 months ago
Ah si, il restait un point pour lequel je suis pas complètement sûr, c'est les boutons des formulaires.
L'idée étant de cibler tous les boutons qui permettent de soumettre le formulaire.
Pour l'instant, je cible comme ça :
.formulaire_spip input.submit,
.formulaire_spip button {
…
}
Mais peut-être que cibler tous les tags <button>
est trop large ?
J'ai vu aussi une référence à des input.reset dans forms.css, mais je sais pas trop si c'est utilisé ou pas.
Le but étant d'avoir un sélecteur le plus concis possible, parcequ'il est répété moultes fois (aaah, que je regrette sass et ses @extend).
Avis bienvenus.
#52
Updated by b b 5 months ago
tcharlss 🐽 a écrit :
- J'ai aussi mis quelques animations au survol des icônes. Bon là j'ai pas encore assez de recul pour voir si c'est pas trop distrayant à l'usage. Mais j'aime bien le petit effet bling.
Tout ça me semble top, les animations sont choupi, mais j'ai un doute, surtout sur le fond danger animé qui fait défiler les hachures qui perturbe pas mal la lecture même si c'est mignon :) Mais, celles sur les add/del/etc ne me semblent pas poser de pb de lisibilité.
PS : merci pour tout le détail, la page de démo et le screencast !
#53
Updated by tcharlss 🐽 5 months ago
mais j'ai un doute, surtout sur le fond danger animé qui fait défiler les hachures qui perturbe pas mal la lecture même si c'est mignon :)
Oui c'est sans doute la touche de trop, je vais la revert celle-là.
#54
Updated by PIerre LASZCZAK 5 months ago
tcharlss 🐽 a écrit :
Pour l*'icone export* est ce que c'est possible de faire un flip horizontal afin de bine voir la diff par rapport à export?
#56
Updated by RastaPopoulos ♥ 5 months ago
Je suis d'accord que les deux se distinguent extrêmement mal, ça va pas. Mais s'il faut en changer je dirais plutôt celle d'import, car la majorité des utilisations c'est dans des sites où on lit de gauche à droite, et pour l'export ça parait plus logique d'avoir "notre site" représenté par le carré à gauche, qui exporte vers l'extérieur vers la droite.
#57
Updated by RastaPopoulos ♥ 5 months ago
Comme ça ne se voit pas dans les images, j'ai une question : est-ce que ça prend bien en compte pour les simples <input> submit aussi, pas juste <button> ?
#58
Updated by RealET 🔸 5 months ago
Bonjour,
J'ai voulu tester.Et j'ai cette erreur :
Fatal error: Uncaught Error: Call to undefined function ecrire_fichier_calcule_si_modifie() in C:\laragon\www\spip33\plugins-dist\compresseur\inc\compresseur.php on line 302
( ! ) Error: Call to undefined function ecrire_fichier_calcule_si_modifie() in C:\laragon\www\spip33\plugins-dist\compresseur\inc\compresseur.php on line 302
Call Stack
- Time Memory Function Location
1 0.0004 430392 {main}( ) ...\index.php:0
2 0.1314 8997432 exec_admin_plugin_dist( ) ...\index.php:166
3 0.3552 11321248 inc_commencer_page_dist( ) ...\admin_plugin.php:99
4 0.3566 11366584 init_entete( ) ...\commencer_page.php:59
5 0.3597 11445224 init_head( ) ...\commencer_page.php:98
6 0.3597 11445600 recuperer_fond( ) ...\commencer_page.php:113
7 0.3673 11547768 evaluer_fond( ) ...\utils.php:3211
8 0.3673 11547768 inclure_page( ) ...\assembler.php:651
9 0.3789 11699792 public_produire_page_dist( ) ...\assembler.php:279
10 0.3789 11699888 public_parametrer_dist( ) ...\assembler.php:315
11 0.4253 12770192 html_12cef13bf48781313bd9610ff114fef8( ) ...\parametrer.php:128
12 0.5928 14417704 pipeline( ) ...\html_12cef13bf48781313bd9610ff114fef8.php:28
13 0.5928 14417784 execute_pipeline_header_prive( ) ...\utils.php:265
14 0.6592 14733152 minipipe( ) ...\charger_pipelines.php:715
15 0.6592 14733152 compresseur_header_prive( ) ...\utils.php:199
16 0.6598 14737384 compacte_head( ) ...\compresseur_pipeline.php:36
17 0.6609 14802416 compacte_head_files( ) ...\compresseur_fonctions.php:138
18 0.6652 14869280 concatener_fichiers( ) ...\compresseur.php:206
19 0.6675 14927472 compresseur_callback_prepare_css( ) ...\compresseur_concatener.php:81
#59
Updated by tcharlss 🐽 5 months ago
J'ai changé l'icône d'export plutôt que l'autre comme le suggérait RastaPopoulos, ça me semble plus logique.
@RealET : ça persiste après un recalcul ? J'ai une erreur php quand je bascule du master sur cette branche mais c'est normal car elle est en retard de quelques mois sur le master, donc certaines fonctions invoquées dans les fichiers mis en cache manquent. Par contre ton erreur ne semble pas concerner le dépôt spip mais un des plugins dist, donc je vois pas trop pourquoi elle apparaît juste là.
@RastaPopoulos : j'en parle justement plus haut : https://core.spip.net/issues/4468#note-51
#60
Updated by RealET 🔸 5 months ago
Alors, même en vidant entièrement le dossier tmp, j'ai :
Fatal error: Uncaught Error: Call to undefined function ecrire_fichier_calcule_si_modifie() in C:\laragon\www\spip33\plugins-dist\compresseur\inc\compresseur.php:302 Stack trace: #0 C:\laragon\www\spip33\plugins-dist\compresseur\inc\compresseur_concatener.php(81): compresseur_callback_prepare_css('prive/themes/sp...') #1 C:\laragon\www\spip33\plugins-dist\compresseur\inc\compresseur.php(206): concatener_fichiers(Array, 'css', Array) #2 C:\laragon\www\spip33\plugins-dist\compresseur\compresseur_fonctions.php(138): compacte_head_files('\r\n<!DOCTYPE htm...', 'css') #3 C:\laragon\www\spip33\ecrire\public\sandbox.php(180): compacte_head('\r\n<!DOCTYPE htm...') #4 C:\laragon\www\spip33\ecrire\public\composer.php(243): sandbox_filtrer_squelette(Array, '\r\n<!DOCTYPE htm...', Array, Array) #5 C:\laragon\www\spip33\ecrire\public\composer.php(93) : eval()'d code(117): analyse_resultat_skel('html_f4375c6230...', Array, '\r\n<!DOCTYPE htm...', 'prive/login.htm...') #6 C:\laragon\www\spip33\ecrire\public\parametrer.php(128): html_f43 in C:\laragon\www\spip33\plugins-dist\compresseur\inc\compresseur.php on line 302
#62
Updated by marcimat 🌻 5 months ago
- Status changed from En cours to Fermé
- Resolution set to fixed
Je ferme ce long fil car c’est intégré, et j’en ouvre un autre pour causer les détails suite à ces changements.