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

Closed
opened 1 year ago by marcimat · 80 comments
marcimat commented 1 year ago
Owner

Je propose de parler ici des détails et corrections éventuelles à apporter suite à l’intégration de #4468.
Déjà, c’est hyper bien globalement (ne me faites pas dire le contraire :))

Voilà ce que j’ai observé pour ma part, qui me chagrine.

Je propose de parler ici des détails et corrections éventuelles à apporter suite à l’intégration de #4468. Déjà, c’est hyper bien globalement (ne me faites pas dire le contraire :)) Voilà ce que j’ai observé pour ma part, qui me chagrine.
Poster
Owner

Chiotte, redmine a soumis en ajoutant la description du fichier, alors que j’avais pas fini de rédiger le ticket :)

Chiotte, redmine a soumis en ajoutant la description du fichier, alors que j’avais pas fini de rédiger le ticket :)
Poster
Owner

Donc, il y a quelques petits éléments à corriger je pense éventuellement, mais le plus gênant je trouve, c’est la couleur de hover d’un fond de liste, ou de :odd d’une table (ou l’autre) avec les boutons non hover (gris clair). C’est assez peu élégant je trouve. Cela dit j’ai pas forcément de réponse, si ce n’est à adapter ces couleurs de background des fonds de liste ou table...

Enfin, du coup j’aimerais bien que les icones d’action rapide soient comme les autres, svg avec l’animation :p (todo #rêve)

Donc, il y a quelques petits éléments à corriger je pense éventuellement, mais le plus gênant je trouve, c’est la couleur de hover d’un fond de liste, ou de :odd d’une table (ou l’autre) avec les boutons non hover (gris clair). C’est assez peu élégant je trouve. Cela dit j’ai pas forcément de réponse, si ce n’est à adapter ces couleurs de background des fonds de liste ou table... Enfin, du coup j’aimerais bien que les icones d’action rapide soient comme les autres, svg avec l’animation :p (todo #rêve)
Poster
Owner

Version cible mise à 4.0

**Version cible mise à 4.0**
b_b commented 1 year ago
Owner

Comme je le disais sur IRC, je suis étonné de la teinte "rose délavé' des boutons quand la couleur de mes préférences en le gris, exemple en mode avant/après en pièce jointe.

Comme je le disais sur IRC, je suis étonné de la teinte "rose délavé' des boutons quand la couleur de mes préférences en le gris, exemple en mode avant/après en pièce jointe.
Owner

le plus gênant je trouve, c’est la couleur de hover d’un fond de liste, ou de :odd d’une table (ou l’autre) avec les boutons non hover (gris clair). […] Cela dit j’ai pas forcément de réponse, si ce n’est à adapter ces couleurs de background des fonds de liste ou table...

Oui c'est pas très heureux dans ces cas.
Une technique c'est d'utiliser une couleur transparente pour les boutons, comme ça c'est eux qui s'adaptent au contexte et pas besoin de modifier plein d'éléments. Mais ça ne fonctionne bien que si les boutons sont sur des fonds de couleurs relativement claires (cf. image de test en pj). Et pour ça il faudrait aussi ajouter un filtre à fonction d'images pour convertir une couleur hexa en hsla.

Image marge_et_alignement_supprimer_mot.png

Dans l'image sur la marge et l'alignement, je note aussi que « supprimer ce mot » et « voir en ligne » n'ont pas la même taille de police, ça ne devrait pas être le cas. Il doit rester des exceptions par-ci par-là, à corriger.

Sur l'alignement en lui même, je suis pas sûr qu'il faille décaler toutes les icônes horizontales juste au cas-où elles soient en vis-à-vis d'une icône avec un fond de couleur. Imaginons qu'il n'y ait pas l'icône "supprimer", on se retrouverait avec l'icône « voir en ligne » décalée pour rien.

je suis étonné de la teinte "rose délavé' des boutons quand la couleur de mes préférences en le gris

T'as choisi la couleur qui pose problème :p
En fait celle-là c'est pas du gris pur à la base. Or dans les styles ça prend la couleur utilisateur, ça l'éclaircit et ça lui met une saturation en dur. Donc dans ce cas précis on se retrouve avec une couleur plus saturée que celle d'origine, c'est ballot.
Bon, clairement il faut la baisser.

Image choisir_dans_mediatheque_non_style-1.png

Pour les <input> et autres <button>, j'ai volontairement restreint la portée pour éviter d'éventuels effets de bord.
C'est à dire dire que le style s'applique uniquement aux boutons situés dans un .formulaire_spip, et auxquels on a mis la classe .submit.
Concrètement le sélecteur c'est ça :

.formulaire_spip input.submit,
.formulaire_spip button { … }

Donc je sais pas, c'est trop restreint, faut élargir la portée ?

En tout cas, pour ce cas précis il ne s'agit pas d'un formulaire donc pas de styles pour le bouton.
Pour ces cas il suffirait d'ajouter la classe .bouton à cet endroit, et zou.

> le plus gênant je trouve, c’est la couleur de hover d’un fond de liste, ou de :odd d’une table (ou l’autre) avec les boutons non hover (gris clair). […] Cela dit j’ai pas forcément de réponse, si ce n’est à adapter ces couleurs de background des fonds de liste ou table... Oui c'est pas très heureux dans ces cas. Une technique c'est d'utiliser une couleur transparente pour les boutons, comme ça c'est eux qui s'adaptent au contexte et pas besoin de modifier plein d'éléments. Mais ça ne fonctionne bien que si les boutons sont sur des fonds de couleurs relativement claires (cf. image de test en pj). Et pour ça il faudrait aussi ajouter un filtre à fonction d'images pour convertir une couleur hexa en hsla. > Image marge_et_alignement_supprimer_mot.png ![](/redmine/1188/marge_et_alignement_supprimer_mot.png) Dans l'image sur la marge et l'alignement, je note aussi que « supprimer ce mot » et « voir en ligne » n'ont pas la même taille de police, ça ne devrait pas être le cas. Il doit rester des exceptions par-ci par-là, à corriger. Sur l'alignement en lui même, je suis pas sûr qu'il faille décaler toutes les icônes horizontales juste au cas-où elles soient en vis-à-vis d'une icône avec un fond de couleur. Imaginons qu'il n'y ait pas l'icône "supprimer", on se retrouverait avec l'icône « voir en ligne » décalée pour rien. > je suis étonné de la teinte "rose délavé' des boutons quand la couleur de mes préférences en le gris T'as choisi *la* couleur qui pose problème :p En fait celle-là c'est pas du gris pur à la base. Or dans les styles ça prend la couleur utilisateur, ça l'éclaircit et ça lui met une saturation en dur. Donc dans ce cas précis on se retrouve avec une couleur plus saturée que celle d'origine, c'est ballot. Bon, clairement il faut la baisser. > Image choisir_dans_mediatheque_non_style-1.png ![](/redmine/1191/choisir_dans_mediatheque_non_style.png) Pour les `<input>` et autres `<button>`, j'ai volontairement restreint la portée pour éviter d'éventuels effets de bord. C'est à dire dire que le style s'applique uniquement aux boutons situés dans un .formulaire_spip, et auxquels on a mis la classe .submit. Concrètement le sélecteur c'est ça : ``` .formulaire_spip input.submit, .formulaire_spip button { … } ``` Donc je sais pas, c'est trop restreint, faut élargir la portée ? En tout cas, pour ce cas précis il ne s'agit pas d'un formulaire donc pas de styles pour le bouton. Pour ces cas il suffirait d'ajouter la classe .bouton à cet endroit, et zou.

Pour les vrais boutons je vois pas pourquoi il y aurait des boutons sans les styles, vu que le but est d'unifier. La classe je la vois pour quand c'est pas un bouton, pour mettre le même style quand c'est un lien (un faux bouton). Mais quand c'est déjà un vrai bouton (= soit input submit, soit tous les buttons), à priori ça devrait avoir la même couleur, le même aspect.

Après je sais pas… dans d'autres frameworks, par ex bootstrap fait ce choix : ça impose de mettre la classe sur TOUS les éléments où on veut, y compris les déjà vrais input et button, mais ça fait trop modifier des choses d'après moi… (et je déteste quand le framework CSS oblige à modifier à mort le HTML à en dépendre)

Pour les vrais boutons je vois pas pourquoi il y aurait des boutons sans les styles, vu que le but est d'unifier. La classe je la vois pour quand c'est pas un bouton, pour mettre le même style quand c'est un lien (un faux bouton). Mais quand c'est déjà un vrai bouton (= soit input submit, soit tous les buttons), à priori ça devrait avoir la même couleur, le même aspect. Après je sais pas… dans d'autres frameworks, par ex bootstrap fait ce choix : ça impose de mettre la classe sur TOUS les éléments où on veut, y compris les déjà vrais input et button, mais ça fait trop modifier des choses d'après moi… (et je déteste quand le framework CSS oblige à modifier à mort le HTML à en dépendre)
Owner

Autre glitch rapporté par _Eric_33 : dans SVP la liste des dépôts utilise la classe .bouton sur les th et les td, donc ça merdouille.

Autre glitch rapporté par _Eric_33 : dans SVP la liste des dépôts utilise la classe .bouton sur les th et les td, donc ça merdouille.
Owner

Autre glitch rapporté par _Eric_33 : dans SVP la liste des dépôts utilise la classe .bouton sur les th et les td, donc ça merdouille.

Sur ce point amha on peut fixer le bug du côté de SVP.

> Autre glitch rapporté par _Eric_33 : dans SVP la liste des dépôts utilise la classe .bouton sur les th et les td, donc ça merdouille. Sur ce point amha on peut fixer le bug du côté de SVP.

Ouais là c'est le code de SVP qui est boulet :p qu'est-ce que fichent des classes "bouton" (singulier) sur des ? Donc oui à corriger là :)

Ouais là c'est le code de SVP qui est boulet :p qu'est-ce que fichent des classes "bouton" (singulier) sur des <th> ? Donc oui à corriger là :)
Owner

Mais quand c'est déjà un vrai bouton (= soit input submit, soit tous les buttons), à priori ça devrait avoir la même couleur, le même aspect.

Je sais pas, ça fait un peu peur quand même de tout cibler.
Par exemple dans les widgets javascript, ça peut arriver qu'ils ajoutent des <button> déjà stylés à leur sauce, et ça provoquerait sans doute des conflits.
En tout cas pour les <input type="submit">, la charte impose déjà de mettre une classe .submit (ou .reset aussi je crois), au moins pour eux ça semble ok de restreindre à cette classe.
Et donc pour les <button>, je sais pas, c'est le doute.

> Mais quand c'est déjà un vrai bouton (= soit input submit, soit tous les buttons), à priori ça devrait avoir la même couleur, le même aspect. Je sais pas, ça fait un peu peur quand même de tout cibler. Par exemple dans les widgets javascript, ça peut arriver qu'ils ajoutent des `<button>` déjà stylés à leur sauce, et ça provoquerait sans doute des conflits. En tout cas pour les `<input type="submit">`, la charte impose déjà de mettre une classe .submit (ou .reset aussi je crois), au moins pour eux ça semble ok de restreindre à cette classe. Et donc pour les `<button>`, je sais pas, c'est le doute.
Poster
Owner

Yop :)

Je viens de noter autre chose, pas très grave mais il me semble que si c’est en svg, ça peut être mieux :
sur les boutons avec une icone à gauche (.add, .edit, .del, .config...), le hover a un effet de transition sur le background-color et le texte, mais bascule l’icone dans un autre état de couleur sans transition : du coup, ça fait un petit flash désagréable non ? (l’icone change de couleur instantanément, tandis que le background et texte le fait avec un fading...).

Yop :) Je viens de noter autre chose, pas très grave mais il me semble que si c’est en svg, ça peut être mieux : sur les boutons avec une icone à gauche (.add, .edit, .del, .config...), le hover a un effet de transition sur le background-color et le texte, mais bascule l’icone dans un autre état de couleur sans transition : du coup, ça fait un petit flash désagréable non ? (l’icone change de couleur instantanément, tandis que le background et texte le fait avec un fading...).
Owner

le hover a un effet de transition sur le background-color et le texte, mais bascule l’icone dans un autre état de couleur sans transition : du coup, ça fait un petit flash désagréable non ?

Je ne crois pas que mettre une transition soit possible car ces svg ne sont pas embed, ce sont des background-image sur un :before (j'ai ajouté des variantes truc-inverse-xx.svg pour chaque icône).
Peut-être que le flash est dû au temps de latence du 1er chargement de l'image lors du survol, à ce compte là il faudrait peut-être faire un sprite.

> le hover a un effet de transition sur le background-color et le texte, mais bascule l’icone dans un autre état de couleur sans transition : du coup, ça fait un petit flash désagréable non ? Je ne crois pas que mettre une transition soit possible car ces svg ne sont pas embed, ce sont des background-image sur un :before (j'ai ajouté des variantes truc-inverse-xx.svg pour chaque icône). Peut-être que le flash est dû au temps de latence du 1er chargement de l'image lors du survol, à ce compte là il faudrait peut-être faire un sprite.
Poster
Owner

Bah c’est pas grave. Non c’est juste que l’icone passe instantanément de noir à blanc, mais pas le texte ni le background. C’est tout. Rien de dramatique.

Bah c’est pas grave. Non c’est juste que l’icone passe instantanément de noir à blanc, mais pas le texte ni le background. C’est tout. Rien de dramatique.
Owner

Je crois que j'ai trouvé un effet de bord sur les boutons des items de la liste des traductions d'un article, exemple ici :

https://www.spip.net/ecrire/?exec=article&id_article=6431

La même liste sur contrib :

https://contrib.spip.net/ecrire/?exec=article&id_article=4189

La première n'affiche plus l'icone du micro dans les boutons, la seconde si.
Statut changé à En cours

Je crois que j'ai trouvé un effet de bord sur les boutons des items de la liste des traductions d'un article, exemple ici : https://www.spip.net/ecrire/?exec=article&id_article=6431 La même liste sur contrib : https://contrib.spip.net/ecrire/?exec=article&id_article=4189 La première n'affiche plus l'icone du micro dans les boutons, la seconde si. **Statut changé à En cours**
Owner

Attention coupage de cheveux en 4 :

Actuellement il y a plusieurs variantes de tailles : .s12, .s16, .s24 et .s32
J'ai repris ça de ce qui existe pour le composant .icone

Sauf que pour ce composant, c'est jamais une classe qu'on met à la main, c'est le filtre icone_xxx qui la rajoute en fonction de l'image : patate-24.png, courgette-32.png, etc.
Et donc là ça a du sens parceque ça indique précisément la taille de l'icône.

Sauf que pour les boutons, l'icône est totalement optionnelle.
Et plutôt qu'une classe qui dirait : "je veux un bouton avec une icone de 16px", à priori on pense plutôt : "je veux un bouton de taille normale, de grande taille", etc. Et l'icône s'adapte en fonction, on se fiche un peu qu'elle fasse exactement 16px ou pas.

Donc tout ça pour dire que pour les boutons, il est encore temps de changer en .petit, .moyen et .grand à la place de .s16 et cie.
Ça va à tout le monde ?

Attention coupage de cheveux en 4 : Actuellement il y a plusieurs variantes de tailles : .s12, .s16, .s24 et .s32 J'ai repris ça de ce qui existe pour le composant .icone Sauf que pour ce composant, c'est jamais une classe qu'on met à la main, c'est le filtre icone_xxx qui la rajoute en fonction de l'image : patate-24.png, courgette-32.png, etc. Et donc là ça a du sens parceque ça indique précisément la taille de l'icône. Sauf que pour les boutons, l'icône est totalement optionnelle. Et plutôt qu'une classe qui dirait : "je veux un bouton avec une icone de 16px", à priori on pense plutôt : "je veux un bouton de taille normale, de grande taille", etc. Et l'icône s'adapte en fonction, on se fiche un peu qu'elle fasse exactement 16px ou pas. Donc tout ça pour dire que pour les boutons, il est encore temps de changer en .petit, .moyen et .grand à la place de .s16 et cie. Ça va à tout le monde ?

Ouais, trois tailles suffisent je pense. Normal sans classe. Plus petit. Plus grand.

Ouais, trois tailles suffisent je pense. Normal sans classe. Plus petit. Plus grand.
Owner

Je crois que j'ai trouvé un effet de bord sur les boutons des items de la liste des traductions d'un article, exemple ici :

Ça semble pas être un problème de CSS mais carrément la balise image qui manque dans ces boutons : langues-off-12.gif
Je sais pas, à priori les modifs faites sur les boutons ont pas touché à ces gif (il y a juste des images svg en plus, mais aucune image supprimée).

> Je crois que j'ai trouvé un effet de bord sur les boutons des items de la liste des traductions d'un article, exemple ici : Ça semble pas être un problème de CSS mais carrément la balise image qui manque dans ces boutons : langues-off-12.gif Je sais pas, à priori les modifs faites sur les boutons ont pas touché à ces gif (il y a juste des images svg en plus, mais aucune image supprimée).
Owner

Donc je confirme : un [(#CHEMIN_IMAGE{langues-off-12.gif}|var_dump)] renvoie false
Cf. "prive/objets/liste/articles-trad.html#L33":https://git.spip.net/spip/spip/src/branch/master/prive/objets/liste/articles-trad.html#L33

Je retrouve pas cette image dans le dossier prive/

Donc je confirme : un `[(#CHEMIN_IMAGE{langues-off-12.gif}|var_dump)]` renvoie `false` Cf. "prive/objets/liste/articles-trad.html#L33":https://git.spip.net/spip/spip/src/branch/master/prive/objets/liste/articles-trad.html#L33 Je retrouve pas cette image dans le dossier prive/
Owner

C'est depuis "d311d0ae27":d311d0ae27
Elle a pas été remplacée par un équivalent svg ou png, sans doute un oubli

C'est depuis "d311d0ae27":https://git.spip.net/spip/spip/commit/d311d0ae27ce97368017b041e7d56632ab63dfe3 Elle a pas été remplacée par un équivalent svg ou png, sans doute un oubli
Owner

Ouais, trois tailles suffisent je pense. Normal sans classe. Plus petit. Plus grand.

Donc je suis parti sur 2 variantes .mini et .large, ça devrait suffire.
On peut également les mettre sur un groupe de boutons, ça évite d'avoir à les mettre sur chaque bouton du groupe.
Ça c'est commité.

Autre sujet : les espèces de pseudo boutons avec des crochets qu'on trouve dans les .toggle_box_link : [Changer], [Ajouter une patate]… Notamment dans le formulaire editer_liens.
Tant qu'à fignoler, je suis d'avis de supprimer ces crochets.
À priori juste avec les classes .link.mini, ça devrait suffire (sur le bouton lui-même, on touche pas à .toggle_box_link bien sûr).

Un peu sur le même sujet, toujours dans editer_liens il y a aussi les boutons « Retirer cette patate ».
Actuellement ça merdouille un peu car il y a des styles propres au formulaire qui se téléscopent avec la classe générique .link.
Je pense que maintenant le générique suffit, plus besoin de styles précis sur ce bouton : avec les classes .link.mini.supprimer on a ce qu'il faut.
Et notamment, ça permettrait d'harmoniser l'apparence entre les boutons « Ajouter une patate » et « Retirer cette patate ».
Dans l'image-jointe il y a ce que ça donnerait avec le "avant" sur les mots-clés et le "après" sur les auteurs.
Mais donc idéalement ça supposerait de changer ces classes dans toutes les listes patate-lies.html de la dist, et faire en sorte de garder un affichage correct pour les autres plugins.

> Ouais, trois tailles suffisent je pense. Normal sans classe. Plus petit. Plus grand. Donc je suis parti sur 2 variantes `.mini` et `.large`, ça devrait suffire. On peut également les mettre sur un groupe de boutons, ça évite d'avoir à les mettre sur chaque bouton du groupe. Ça c'est commité. ![](/redmine/1200/4562_tailles.png) Autre sujet : les espèces de pseudo boutons avec des crochets qu'on trouve dans les `.toggle_box_link` : `[Changer]`, `[Ajouter une patate]`… Notamment dans le formulaire editer_liens. Tant qu'à fignoler, je suis d'avis de supprimer ces crochets. À priori juste avec les classes `.link.mini`, ça devrait suffire (sur le bouton lui-même, on touche pas à `.toggle_box_link` bien sûr). Un peu sur le même sujet, toujours dans editer_liens il y a aussi les boutons « Retirer cette patate ». Actuellement ça merdouille un peu car il y a des styles propres au formulaire qui se téléscopent avec la classe générique `.link`. Je pense que maintenant le générique suffit, plus besoin de styles précis sur ce bouton : avec les classes `.link.mini.supprimer` on a ce qu'il faut. Et notamment, ça permettrait d'harmoniser l'apparence entre les boutons « Ajouter une patate » et « Retirer cette patate ». Dans l'image-jointe il y a ce que ça donnerait avec le "avant" sur les mots-clés et le "après" sur les auteurs. Mais donc idéalement ça supposerait de changer ces classes dans toutes les listes patate-lies.html de la dist, et faire en sorte de garder un affichage correct pour les autres plugins. ![](/redmine/1202/4562_link_toggle.png)
Owner

Edit image

Edit image
Owner

Gniiiiii

Gniiiiii
Poster
Owner

Ça semble très bien la proposition tcharles sur les patates. :)

Ça semble très bien la proposition tcharles sur les patates. :)

Mais tellement… enlever tous ces faux liens-boutons avec crochet horriblement laids…

Par contre je me pose la question, si c'est vraiment pertinent de leur mettre "link". Les crochets c'était justement pour signifier que c'était des boutons et pas des liens, car il n'y avait justement pas à l'époque de classe "bouton" permettant de simuler l'apparence d'un bouton sur une balise de lien. Il s'agit d'un "départ d'action" : ajouter quelque chose. Donc je suis d'avis que ça devrait avoir l'apparence (et donc la sémantique visuelle) d'un bouton. Donc uniquement "mini" mais sans "link".

Mais tellement… enlever tous ces faux liens-boutons avec crochet horriblement laids… Par contre je me pose la question, si c'est vraiment pertinent de leur mettre "link". Les crochets c'était justement pour signifier que c'était des boutons et pas des liens, car il n'y avait justement pas à l'époque de classe "bouton" permettant de simuler l'apparence d'un bouton sur une balise de lien. Il s'agit d'un "départ d'action" : ajouter quelque chose. Donc je suis d'avis que ça devrait avoir l'apparence (et donc la sémantique visuelle) d'un bouton. Donc uniquement "mini" mais sans "link".
Owner

Ah marcimat, pour le survol qui rend pas génial en certains endroits : ça ne semble concerner que peu de composants, j'ai repéré ça que sur les listes d'items pour l'instant : .liste_items.
À ce compte là, on pourrait essayer d'ajouter une bordure aux boutons spécifiquement au survol de ces composants, cf. image jointe.
T'en penses quoi ?

Ah marcimat, pour le survol qui rend pas génial en certains endroits : ça ne semble concerner que peu de composants, j'ai repéré ça que sur les listes d'items pour l'instant : `.liste_items`. À ce compte là, on pourrait essayer d'ajouter une bordure aux boutons spécifiquement au survol de ces composants, cf. image jointe. T'en penses quoi ? ![](/redmine/1203/4562_hover.png)
Poster
Owner

Ah mais je te fais une entière et totale confiance `tcharles !
(et oui, ça semble bien)

Ah mais je te fais une entière et totale confiance `tcharles ! (et oui, ça semble bien)
Owner

Par contre je me pose la question, si c'est vraiment pertinent de leur mettre "link".

Sans le .link ça donnerait ça.
Ça fait un peu chargé non ?
Et on retombe sur le problème quand un bouton est sur un élément qui a un fond de couleur proche... ostie de criss !

> Par contre je me pose la question, si c'est vraiment pertinent de leur mettre "link". Sans le .link ça donnerait ça. Ça fait un peu chargé non ? Et on retombe sur le problème quand un bouton est sur un élément qui a un fond de couleur proche... ostie de criss ! ![](/redmine/1204/4562_link_toggle_pas_link.png)

Je parlais seulement de celle avec les crochets immondes tcharlss, pour ajouter :)
Pour les autres là oui en link, puisque c'est pour retirer, supprimer quelque chose, donc en retrait.

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

Peut-être l'inverse aussi, le retrait est plus gros que l'ajout : ça ne va pas. C'est le retrait qui devrait être en mini+link (très peu mis en avant), et l'ajout en normal, ni link, ni peut-être mini non plus.

Je parlais seulement de celle avec les crochets immondes tcharlss, pour ajouter :) Pour les autres là oui en link, puisque c'est pour retirer, supprimer quelque chose, donc en retrait. Mais pour l'ajout là c'est bizarre on voit pas le fond, c'est un peu nul, en tout cas pour cette couleur. Peut-être l'inverse aussi, le retrait est plus gros que l'ajout : ça ne va pas. C'est le retrait qui devrait être en mini+link (très peu mis en avant), et l'ajout en normal, ni link, ni peut-être mini non plus.
Owner

RastaPopoulos ♥ a écrit :

Mais pour l'ajout là c'est bizarre on voit pas le fond, c'est un peu nul, en tout cas pour cette couleur.
Peut-être l'inverse aussi, le retrait est plus gros que l'ajout : ça ne va pas. C'est le retrait qui devrait être en mini+link (très peu mis en avant), et l'ajout en normal, ni link, ni peut-être mini non plus.

+1 et +1

RastaPopoulos ♥ a écrit : > Mais pour l'ajout là c'est bizarre on voit pas le fond, c'est un peu nul, en tout cas pour cette couleur. > Peut-être l'inverse aussi, le retrait est plus gros que l'ajout : ça ne va pas. C'est le retrait qui devrait être en mini+link (très peu mis en avant), et l'ajout en normal, ni link, ni peut-être mini non plus. +1 et +1
Owner

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.

> 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.

Mais si l'ajout il est mis en .primary, ça sera plus gris sur gris non ? Un bouton de la couleur dominante.

Mais si l'ajout il est mis en .primary, ça sera plus gris sur gris non ? Un bouton de la couleur dominante.

Un petit bug sur cextra interface

Un petit bug sur cextra interface ![](https://pic.infini.fr/7fkarpU8/wFqWOwap.png)
Owner

Mais si l'ajout il est mis en .primary, ça sera plus gris sur gris non ? Un bouton de la couleur dominante.

Ça contourne en effet le problème. Mais je sais pas, à 1ère vue ça fait un peu chargé tu trouves pas ?
Faut imaginer avec plusieurs formulaires editer_liens qui se suivent potentiellement.

> Mais si l'ajout il est mis en .primary, ça sera plus gris sur gris non ? Un bouton de la couleur dominante. Ça contourne en effet le problème. Mais je sais pas, à 1ère vue ça fait un peu chargé tu trouves pas ? Faut imaginer avec plusieurs formulaires editer_liens qui se suivent potentiellement. ![](/redmine/1206/4562_link_toggle_primary.png)

Moi ça ne me choque pas, au contraire même, que les boutons "Ajouter XXX" soient bien en vue. D'autant plus qu'ils sont déplacés différent de là où on les voit dans d'autres listes (sous les listes d'objets ailleurs), et qu'il n'ont pas d'icône (et tant mieux). En plus apparemment c'est légèrement atténué par défaut, tant que pas survolé.

Ça me parait très bien là ! :)

Moi ça ne me choque pas, au contraire même, que les boutons "Ajouter XXX" soient bien en vue. D'autant plus qu'ils sont déplacés différent de là où on les voit dans d'autres listes (sous les listes d'objets ailleurs), et qu'il n'ont pas d'icône (et tant mieux). En plus apparemment c'est légèrement atténué par défaut, tant que pas survolé. Ça me parait très bien là ! :)
Owner

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":https://core.spip.net/issues/4429 et "#3017":https://core.spip.net/issues/4429.

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.

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":https://core.spip.net/issues/4429 et "#3017":https://core.spip.net/issues/4429. 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. ![](/redmine/1207/4562_svp2.png)
Poster
Owner

ça semble pas mal pour SVP

ça semble pas mal pour SVP
Owner

Remarque tant qu'à faire, autant se rapprocher de la maquette de Rasta non ? (la plus simple, la v1 : https://core.spip.net/attachments/download/1171/svp.html).
Ça ferait une étape intermédiaire avant la version finale.
Pour l'instant il ne s'agit vraiment que de l'habillage, pour la finaliser par la suite il ne resterait que la gestion plus avancée des messages et boutons de mise à jour (et éventuellement les boutons déroulants si c'est la v2 qui est retenue).

Je reviens à la charge pour les boutons editer_liens et cie là, je suis quand même pas 100% convaincu par l'utilisation de la variante .principal à cet endroit, ça attire beaucoup l'attention. Le .link me parait plus sobre. Du coup je sais pas, on fait un vote ? On s'en fout ?

Remarque tant qu'à faire, autant se rapprocher de la maquette de Rasta non ? (la plus simple, la v1 : https://core.spip.net/attachments/download/1171/svp.html). Ça ferait une étape intermédiaire avant la version finale. Pour l'instant il ne s'agit vraiment que de l'habillage, pour la finaliser par la suite il ne resterait que la gestion plus avancée des messages et boutons de mise à jour (et éventuellement les boutons déroulants si c'est la v2 qui est retenue). ![](/redmine/1208/4562_svp3.png) Je reviens à la charge pour les boutons editer_liens et cie là, je suis quand même pas 100% convaincu par l'utilisation de la variante .principal à cet endroit, ça attire beaucoup l'attention. Le .link me parait plus sobre. Du coup je sais pas, on fait un vote ? On s'en fout ? ![](/redmine/1209/4562_link_toggle_comparaison.png)

Je continue de trouver ça excellent avec le principal. Ce qui est de la suppression/retrait : c'est en retrait. Ce qui est de l'ajout : c'est bien visible. Avec même deux arguments :

  • les deux (suppression et ajout) doivent avoir des styles bien différents à mon avis
  • et même si on considérait juste l'ajout seul, il doit se voir au premier coup d'œil, sans bouger la souris, voir immédiatement qu'il y a un truc cliquable, sans devoir survoler pour être sûr qu'il y a le curseur qui change

Là ça fait UN élément cliquable bien découpé, bien mis en avant, pour chaque boite différente, c'est excellent comme efficacité. (Pour la date par contre ça pourrait rester en retrait : c'est beaucoup plus rare de changer une date que d'ajouter un mot ou un auteur.)

Je continue de trouver ça excellent avec le principal. Ce qui est de la suppression/retrait : c'est en retrait. Ce qui est de l'ajout : c'est bien visible. Avec même deux arguments : - les deux (suppression et ajout) *doivent* avoir des styles bien différents à mon avis - et même si on considérait juste l'ajout seul, il doit se voir au premier coup d'œil, sans bouger la souris, voir immédiatement qu'il y a un truc cliquable, sans devoir survoler pour être sûr qu'il y a le curseur qui change Là ça fait UN élément cliquable bien découpé, bien mis en avant, pour chaque boite différente, c'est excellent comme efficacité. (Pour la date par contre ça pourrait rester en retrait : c'est beaucoup plus rare de changer une date que d'ajouter un mot ou un auteur.)
Poster
Owner

Comme `tcharlss j’aurais préféré des boutons plus discrets sur les liens de dépliement. Mais c’est déjà très bien comme ça.

Ceci dit, je préfère que ça soit harmonisé globalement

  • je vois pas vraiment de raison à ce que "Changer" de la date soit différent de "Ajouter un X" non ?) : les 2 déplient / ouvrent un formulaire. De même que le "fermer" ensuite qui me semble devrait être pareil.
  • l’argument de Rasta sur différencier les boutons ajouter (le déplier) et retirer, ne me convainc pas particulièrement pour la raison avancée. Concrètement "Ajouter un X" développe le formulaire, laissant apparaître des boutons "Ajouter ce X" qui eux font une action en bdd. Je ne pense pas qu’on doive forcément distinguer visuellement ces différences, mais si tel était le cas, c’est l’action en bdd qui devrait être mis en avant, il me semble (ajouter ce X ou retirer ce X). Le bouton/lien qui sert à déplier peut avoir son style à lui, plus discret ou bien visible comme ici.
  • je suis plus gêné par le fait que "Ajouter ce X" et "Retirer ce X" n’ont pas le même style ! Je m’insurge ! Pourquoi ?
Comme `tcharlss j’aurais préféré des boutons plus discrets sur les liens de dépliement. Mais c’est déjà très bien comme ça. Ceci dit, je préfère que ça soit harmonisé globalement - je vois pas vraiment de raison à ce que "Changer" de la date soit différent de "Ajouter un X" non ?) : les 2 déplient / ouvrent un formulaire. De même que le "fermer" ensuite qui me semble devrait être pareil. - l’argument de Rasta sur différencier les boutons ajouter (le déplier) et retirer, ne me convainc pas particulièrement pour la raison avancée. Concrètement "Ajouter un X" développe le formulaire, laissant apparaître des boutons "Ajouter ce X" qui eux font une action en bdd. Je ne pense pas qu’on doive forcément distinguer visuellement ces différences, mais si tel était le cas, c’est l’action en bdd qui devrait être mis en avant, il me semble (ajouter ce X ou retirer ce X). Le bouton/lien qui sert à déplier peut avoir son style à lui, plus discret ou bien visible comme ici. - je suis plus gêné par le fait que "Ajouter ce X" et "Retirer ce X" n’ont pas le même style ! Je m’insurge ! Pourquoi ?

Pour moi tout ton raisonnement ne convient pas : tu raisonnes uniquement en terme de technicien CSS, alors que je raisonne en terme de sémantique pour l'utilisateurice.

L'utilisateurice qui clique sur "Ajouter un auteur" ne clique absolument pas pour "déplier un formulaire". Ille clique pour ajouter un auteur ! c'est son intention, le but de son action. Ça n'a strictement aucun rapport avec comment techniquement ça va être fait une fois qu'ille aura cliqué : ça pourra être déplier un formulaire, ou une box qui s'ouvre, ou même partir sur une autre page si pas JS du tout : on s'en fout.

Le fait qu'untel soit un lien alors que l'autre un vrai bouton qui va faire une action en BDD, on s'en fout puisque c'est justement le principe même d'avoir certains rares liens qui sont affichés sous forme de boutons, tandis que certains rares boutons sont affichés sous forme de liens.

Ces deux éléments interactifs illustrent admirablement les cas précis et bien réfléchis où on doit échanger la visualisation des boutons et des liens :

  • le "Ajouter un auteur" n'est pas techniquement un bouton de BDD mais il est sémantiquement un bouton car c'est un "démarrage d'action", c'est pour faire un verbe, une action importante : ajouter quelque chose : ça doit être vu comme un bouton au premier coup d'œil
  • tandis que Retirer/Supprimer c'est une vraie action en BDD mais qu'on ne veut pas mettre en avant du tout, donc qu'on rend visuel comme un lien

Changer la date n'a donc de même aucune importance que techniquement en CSS ce soit ci ou ça pareil. La question étant uniquement "quelle intention d'action" ça signifie ? (changer la date), et cette action est-elle importante ou pas ? (non, changer la date est moins important et beaucoup plus rare qu'ajouter un auteur, un mot, un point GIS)

En ergonomie je pense qu'il faut vraiment arrêter de réfléchir en CSS/JS, mais bien en intention de l'utilisateurice.

Pour moi tout ton raisonnement ne convient pas : tu raisonnes uniquement en terme de technicien CSS, alors que je raisonne en terme de sémantique pour l'utilisateurice. L'utilisateurice qui clique sur "Ajouter un auteur" ne clique *absolument pas* pour "déplier un formulaire". Ille clique *pour ajouter un auteur* ! c'est son intention, le but de son action. Ça n'a strictement aucun rapport avec comment techniquement ça va être fait une fois qu'ille aura cliqué : ça pourra être déplier un formulaire, ou une box qui s'ouvre, ou même partir sur une autre page si pas JS du tout : on s'en fout. Le fait qu'untel soit un lien alors que l'autre un vrai bouton qui va faire une action en BDD, on s'en fout puisque c'est justement le principe même d'avoir *certains rares liens* qui sont affichés sous forme de boutons, tandis que certains rares boutons sont affichés sous forme de liens. Ces deux éléments interactifs illustrent admirablement les cas précis et bien réfléchis où on doit échanger la visualisation des boutons et des liens : - le "Ajouter un auteur" n'est pas techniquement un bouton de BDD mais *il est sémantiquement un bouton* car c'est un "démarrage d'action", c'est pour faire un verbe, une action importante : ajouter quelque chose : ça doit être vu comme un bouton au premier coup d'œil - tandis que Retirer/Supprimer c'est une vraie action en BDD mais qu'on ne veut pas mettre en avant du tout, donc qu'on rend visuel comme un lien Changer la date n'a donc de même aucune importance que *techniquement en CSS* ce soit ci ou ça pareil. La question étant uniquement "quelle intention d'action" ça signifie ? (changer la date), et cette action est-elle importante ou pas ? (non, changer la date est moins important et beaucoup plus rare qu'ajouter un auteur, un mot, un point GIS) En ergonomie je pense qu'il faut vraiment arrêter de réfléchir en CSS/JS, mais bien en intention de l'utilisateurice.

Et même le JPG fixe est pour le coup un très bon outil pour cela, l'affordance des éléments d'interaction : avec uniquement le visuel fixe, sans ta souris, sans du tout savoir ce qui va se passer après avoir cliqué : tu dois absolument voir du premier coup d'œil les éléments importants d'interaction, ceux qui sont plus importants et d'usage courant (pas les suppressions donc).

Et pour augmenter on peut même loucher un peu, flouter les yeux, c'est flagrant, pour une boite donnée :

  • en premier je vois un élément clairement identifié comme un bouton, qui donne envie de cliquer pour l'action la plus courante de cette boite
  • en deuxième même les yeux floutés je vois que "Gentillette", "Surprenant", "Sympathique" ont une couleur différente, c'est beaucoup moins important que le bouton mais je comprends que je peux cliquer
  • en troisième, je n'identifie pas spécialement que les "Retirer" sont cliquables (c'est voulu donc bien) mais il y a une petite image rouge qui attire mon œil donc je me dis qu'il y a un truc possible
  • en quatrième tout le reste
    => la hiérarchie est alors super bien cohérente avec le sens de chaque élément

Alors que sans vrai bouton pour les ajouts, pas du tout, avec les yeux floutés je ne vois pas où est l'action la plus importante de la boite (je ne vois même quasi pas l'image, contrairement à la croix rouge).

Et même le JPG fixe est pour le coup un très bon outil pour cela, l'affordance des éléments d'interaction : avec uniquement le visuel fixe, sans ta souris, sans du tout savoir ce qui va se passer après avoir cliqué : tu dois absolument voir du premier coup d'œil les éléments importants d'interaction, ceux qui sont plus importants et d'usage courant (pas les suppressions donc). Et pour augmenter on peut même loucher un peu, flouter les yeux, c'est flagrant, pour une boite donnée : - en premier je vois un élément clairement identifié comme un bouton, qui donne envie de cliquer pour l'action la plus courante de cette boite - en deuxième même les yeux floutés je vois que "Gentillette", "Surprenant", "Sympathique" ont une couleur différente, c'est beaucoup moins important que le bouton mais je comprends que je peux cliquer - en troisième, je n'identifie pas spécialement que les "Retirer" sont cliquables (c'est voulu donc bien) mais il y a une petite image rouge qui attire mon œil donc je me dis qu'il y a un truc possible - en quatrième tout le reste => la hiérarchie est alors super bien cohérente avec le sens de chaque élément Alors que sans vrai bouton pour les ajouts, pas du tout, avec les yeux floutés je ne vois pas où est l'action la plus importante de la boite (je ne vois même quasi pas l'image, contrairement à la croix rouge). ![](/redmine/1211/4562_link_toggle_comparaison_flou.jpg)
There is no content yet.
Poster
Owner

Plusieurs remarques :

  • tu montres un raisonnement avec des personnes ne connaissant pas l’interface. Ok, mais une fois que tu la connais tu sais que le bouton commence l’action d’ajouter une autrice, ou de changer la date. Le fait que ça commence l’action, et non la termine, justement, me semble une indication que c’est n’est pas forcément un .primary à mettre... En général la couleur dominante sert dans les formulaires / boutons à valider / sauvegarder / traiter l’action. Je ne trouve pas que ça soit le plus pertinent ici : ces boutons n’engagent à rien, l’action n’est pas dangereuse. Il faut qu’on sache qu’ils existent et soient visibles, je te l’accorde. Mais je reste sceptique sur l’usage de .primary ici dessus. (encore une fois, ça me va aussi, c’est pas non plus la fin du monde, mais ça fait beaucoup de boutons bien visibles partout dans cette interface, et je vois pas l’utilité de ça : c’est pas mieux pour l’utilisateur·trice si y a un trop plein de boutons bien visibles partout...).
  • pourquoi "retirer ce X" et "ajouter ce X" seraient différent ?
  • et «non, changer la date est moins important et beaucoup plus rare qu'ajouter un auteur, un mot, un point GIS» : je ne suis pas trop d’accord. C’est aussi ton point de vue dans ton contexte et habitudes, mais pour ma part ça m’arrive aussi plus fréquemment de changer des dates, plus que des auteurs ! Mais pour moi, encore une fois, l’important est plus d’être cohérent dans l’ensemble, et justement ne pas faire (trop) de cas particuliers pour ceci ou cela.
Plusieurs remarques : - tu montres un raisonnement avec des personnes ne connaissant pas l’interface. Ok, mais une fois que tu la connais tu sais que le bouton commence l’action d’ajouter une autrice, ou de changer la date. Le fait que ça commence l’action, et non la termine, justement, me semble une indication que c’est n’est pas forcément un .primary à mettre... En général la couleur dominante sert dans les formulaires / boutons à valider / sauvegarder / traiter l’action. Je ne trouve pas que ça soit le plus pertinent ici : ces boutons n’engagent à rien, l’action n’est pas dangereuse. Il faut qu’on sache qu’ils existent et soient visibles, je te l’accorde. Mais je reste sceptique sur l’usage de .primary ici dessus. (encore une fois, ça me va aussi, c’est pas non plus la fin du monde, mais ça fait beaucoup de boutons bien visibles partout dans cette interface, et je vois pas l’utilité de ça : c’est pas mieux pour l’utilisateur·trice si y a un trop plein de boutons bien visibles partout...). - pourquoi "retirer ce X" et "ajouter ce X" seraient différent ? - et «non, changer la date est moins important et beaucoup plus rare qu'ajouter un auteur, un mot, un point GIS» : je ne suis pas trop d’accord. C’est aussi ton point de vue dans ton contexte et habitudes, mais pour ma part ça m’arrive aussi plus fréquemment de changer des dates, plus que des auteurs ! Mais pour moi, encore une fois, l’important est plus d’être cohérent dans l’ensemble, et justement ne pas faire (trop) de cas particuliers pour ceci ou cela.

Moi ça me dérange pas que "Changer" la date ne soit pas en link mais en bouton aussi, au contraire.

Pour le fait que ce soit "primary", c'est un ajout supplémentaire dû à un problème de cohérence CSS dans l'interface : les entêtes de boites, ainsi que d'autres zones dans l'admin, ont un fond gris. Et les vrais boutons normaux (pas link !) : sont gris aussi ! Du coup on les voit pas du tout quand il y a un bouton normal dans une zone comme ça, et c'est même relativement moche.

Je suis plutôt d'accord que les primary devraient être plus rares (quoique pas forcément unique du tout), et mon vrai truc préféré, ça serait qu'il n'y ait pas de fond gris en conflit avec les boutons normaux ; ou inversement que tous les boutons normaux sans variante, le vrai bouton de base sans y toucher, passent sur tous les fonds courants de l'interface : blanc, beige, gris (ça devrait même être un objectif de base ! je trouve c'est un problème ergo important).

Et que donc ces boutons "Ajouter" soit sous forme vraiment de bouton par défaut, mais pas forcément primary, et qu'on les voit quand même bien.

Cela dit, tant que pas résolu ce problème de boutons par défaut sur fond gris, je préfère amplement qu'on soit obligé de rajouter primary (pour détaché du fond gris, et qu'on reconnaisse bien que c'est un bouton), plutôt que pas de forme de bouton du tout.

Pourquoi différent, bah ça me parait clair, de l'ajout c'est plus important (et moins dangereux) qu'une suppression. On met en avant l'ajout (ou au moins en défaut, déjà bien visible), on met en retrait la suppression. Mais pas les deux en retraits au même niveau, comme si c'était égal. C'est un truc de base qui vaut dans 90% des interfaces.

Moi ça me dérange pas que "Changer" la date ne soit pas en link mais en bouton aussi, au contraire. Pour le fait que ce soit "primary", c'est un ajout supplémentaire dû à un problème de cohérence CSS dans l'interface : les entêtes de boites, ainsi que d'autres zones dans l'admin, ont un fond gris. Et les vrais boutons normaux (pas link !) : sont gris aussi ! Du coup on les voit pas du tout quand il y a un bouton normal dans une zone comme ça, et c'est même relativement moche. Je suis plutôt d'accord que les primary devraient être plus rares (quoique pas forcément unique du tout), et mon vrai truc préféré, ça serait qu'il n'y ait pas de fond gris en conflit avec les boutons normaux ; ou inversement que tous les boutons normaux *sans variante*, le vrai bouton de base sans y toucher, passent sur tous les fonds courants de l'interface : blanc, beige, gris (ça devrait même être un objectif de base ! je trouve c'est un problème ergo important). Et que donc ces boutons "Ajouter" soit sous forme vraiment de bouton par défaut, mais pas forcément primary, et qu'on les voit quand même bien. Cela dit, tant que pas résolu ce problème de boutons par défaut sur fond gris, je préfère amplement qu'on soit obligé de rajouter primary (pour détaché du fond gris, et qu'on reconnaisse bien que c'est un bouton), plutôt que pas de forme de bouton du tout. Pourquoi différent, bah ça me parait clair, de l'ajout c'est plus important (et moins dangereux) qu'une suppression. On met en avant l'ajout (ou au moins en défaut, déjà bien visible), on met en retrait la suppression. Mais pas les deux en retraits au même niveau, comme si c'était égal. C'est un truc de base qui vaut dans 90% des interfaces.

Ç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.)

Ç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.)
Owner

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

> 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
Owner

Et les vrais boutons normaux (pas link !) : sont gris aussi ! Du coup on les voit pas du tout quand il y a un bouton normal dans une zone comme ça, et c'est même relativement moche.

Ça c'est corrigé, il y a maintenant une légère bordure quand les boutons se trouvent dans certains éléments identifiés.
En virant le primary ça donne ça

> Et les vrais boutons normaux (pas link !) : sont gris aussi ! Du coup on les voit pas du tout quand il y a un bouton normal dans une zone comme ça, et c'est même relativement moche. Ça c'est corrigé, il y a maintenant une légère bordure quand les boutons se trouvent dans certains éléments identifiés. En virant le primary ça donne ça ![](/redmine/1212/4562_link_toggle_base.png)

Ah ! Je trouve ça déjà légèrement mieux que le link !

Même si je persiste sur les arguments contre le total flat. :) (surtout pour le défaut, primary etc, après qu'il y ait telle variante d'exception pour de rares cas…)
https://uxdesign.cc/design-better-buttons-a5c90a113280

Buttons with shadows are also more “clickable” and noticed much faster, than flat ones. Add a subtle drop shadow in the button to make it stand out from the background more.

Ça peut être vraiment presque plat mais minusculement pas entièrement plat quand même.

Ah ! Je trouve ça déjà légèrement mieux que le link ! Même si je persiste sur les arguments contre le total flat. :) (surtout pour le défaut, primary etc, après qu'il y ait telle variante d'exception pour de rares cas…) https://uxdesign.cc/design-better-buttons-a5c90a113280 > Buttons with shadows are also more “clickable” and noticed much faster, than flat ones. Add a *subtle* drop shadow in the button to make it stand out from the background more. Ça peut être vraiment presque plat *mais* minusculement pas entièrement plat quand même. ![](https://miro.medium.com/max/630/1*V7203_HGzxpqSCo_8FTAAQ.png)
Poster
Owner
  • Ça me semble pas mal pour les editer liens avec la bordure.
  • Je trouve bien aussi ta proposition sur SVP. Cela dit, je suis pas certain qu’il faille aller trop loin sur SVP (par rapport à l’interface que propose Rasta), enfin sauf si ça t’amuse évidemment, car on ne sait pas encore trop comment tout ça va évoluer avec l’arrivée de Composer dans le futur.
  • La réflexion sur un mini effet 3d est intéressante aussi. Du coup, j’imagine que ça ajoute 1px qui peut donner une impression de décentrage vertical ?
  • je persiste à penser que "ajouter" et "retirer" ou toute autre action à cet endroit doit être stylée pareil dans les formulaires de liens (ou autres). Avec ou sans l’applat gris, ça me va, mais choisir serait chouette. J’ai vraiment l’impression d’un bug graphique sinon ! Je suis le seul ?
- Ça me semble pas mal pour les editer liens avec la bordure. - Je trouve bien aussi ta proposition sur SVP. Cela dit, je suis pas certain qu’il faille aller trop loin sur SVP (par rapport à l’interface que propose Rasta), enfin sauf si ça t’amuse évidemment, car on ne sait pas encore trop comment tout ça va évoluer avec l’arrivée de Composer dans le futur. - La réflexion sur un mini effet 3d est intéressante aussi. Du coup, j’imagine que ça ajoute 1px qui peut donner une impression de décentrage vertical ? - je persiste à penser que "ajouter" et "retirer" ou toute autre action à cet endroit doit être stylée pareil dans les formulaires de liens (ou autres). Avec ou sans l’applat gris, ça me va, mais choisir serait chouette. J’ai vraiment l’impression d’un bug graphique sinon ! Je suis le seul ?

Avec un très léger ajout d'1px (fait à l'arrache, on peut faire plus travaillé et subtil bien sûr)

Je persiste à penser que mettre ajouts et suppressions au même niveau hiérarchique visuel est un problème ergonomique :)

Avec un très léger ajout d'1px (fait à l'arrache, on peut faire plus travaillé et subtil bien sûr) ![](/redmine/1213/4562_link_toggle_base_shadow.jpg) Je persiste à penser que mettre ajouts et suppressions au même niveau hiérarchique visuel est un problème ergonomique :)

Pour SVP/Composer, de ce que je sais pour l'instant, on n'est pas encore prêt à avoir un truc complet, comprenant l'interface pour les lambdas. Car au delà de la structure des plugins et leurs dépendances (utiliser le json, composer), ya toujours que les gens doivent pouvoir chercher/récupérer/mettre à jour sans être admin sys, sans avoir accès au serveur, aux fichiers (sans même savoir comment ça marche l'hébergement), juste en étant admin d'un site et en voulant ajouter une fonctionnalité.

Or, en attendant d'avoir trouvé la super solution (cf les pistes qu'on avait dessiné lors de la formation composer), ya vraiment un gros bug ergonomique et même fonctionnel, en obligeant les gens à mettre à jour à la version la plus haute, sans leur montrer à la fois les mises à jour sécu/mineure et les mises à jour majeure, et en pouvant choisir à laquelle monter, et aussi en avertissant pour les majeures que c'est dangereux à vérifier (bref cf le ticket sur les mises à jour). Des gens pètent leur site avec ça, alors qu'ils auraient pu rester à une branche plus basse toujours maintenue (et ça oblige à faire des contorsions sur les plugins d'intégration de libs avec plusieurs préfixes donc plugins pour une même lib). Bref ça me semble au contraire plutôt urgent d'améliorer SVP car ça cause du soucis à pas mal de gens (tous ceux qui ne sont pas chez Nursit, et qui n'ont pas la liste des plugins déjà là bloquée, maintenue par d'autres :p )

Pour SVP/Composer, de ce que je sais pour l'instant, on n'est pas encore prêt à avoir un truc complet, comprenant l'interface pour les lambdas. Car au delà de la structure des plugins et leurs dépendances (utiliser le json, composer), ya toujours que les gens doivent pouvoir chercher/récupérer/mettre à jour sans être admin sys, sans avoir accès au serveur, aux fichiers (sans même savoir comment ça marche l'hébergement), juste en étant admin d'un site et en voulant ajouter une fonctionnalité. Or, en attendant d'avoir trouvé la super solution (cf les pistes qu'on avait dessiné lors de la formation composer), ya vraiment un gros bug ergonomique et même fonctionnel, en obligeant les gens à mettre à jour à la version la plus haute, sans leur montrer à la fois les mises à jour sécu/mineure et les mises à jour majeure, et en pouvant choisir à laquelle monter, et aussi en avertissant pour les majeures que c'est dangereux à vérifier (bref cf le ticket sur les mises à jour). Des gens pètent leur site avec ça, alors qu'ils auraient pu rester à une branche plus basse toujours maintenue (et ça oblige à faire des contorsions sur les plugins d'intégration de libs avec plusieurs préfixes donc plugins pour une même lib). Bref ça me semble au contraire plutôt urgent d'améliorer SVP car ça cause du soucis à pas mal de gens (tous ceux qui ne sont pas chez Nursit, et qui n'ont pas la liste des plugins déjà là bloquée, maintenue par d'autres :p )
Owner

Ouais, une légère-subtile-discrète bordure en bas, ça reste raisonnable. J'ai essayé dans l'inspecteur, c'est pas mal, pourquoi pas.

Il va quand même me falloir plus de lectures pour me faire une idée sur l'argument qui dit que sans ça les gens auraient du mal à identifier les boutons. Même dans les exemples de theming de material - c'est un peu eux qui ont remis au goût du jour les ombres portées et l'idée de relief et de strates verticales - ils donnent des exemples de boutons flat : https://material.io/design/material-theming/overview.html#material-theming
Donc ça me semble pas être un horizon indépassable :p

Concernant la couleur de base, à un moment j'hésitais à partir sur la couleur de l'utilisateur, la version claire.
D'ailleurs vous noterez que c'est celle utilisée pour les boutons des formulaires, comme .boutons a déjà un fond de couleur claire j'ai fait une exception pour eux. Mais c'est bien des boutons de base, pas la variante .principal.
Mais bon, j'étais pas convaincu, je préfèrerais quand même arriver à faire fonctionner le gris clair dans toutes les situations.
Dans Bootstrap, Semantic-ui et cie, les boutons de base sont également gris clairs.

Pour SVP je vais poursuivre dans les tickets liés du coup, sinon on va s'éparpiller.
Juste `marcimat, le truc que je propose c'est ni plus ni moins que la maquette de rasta. C'est même moins d'ailleurs. Et j'ai rien de spécial à ajouter en plus.

Ouais, une légère-subtile-discrète bordure en bas, ça reste raisonnable. J'ai essayé dans l'inspecteur, c'est pas mal, pourquoi pas. Il va quand même me falloir plus de lectures pour me faire une idée sur l'argument qui dit que sans ça les gens auraient du mal à identifier les boutons. Même dans les exemples de theming de material - c'est un peu eux qui ont remis au goût du jour les ombres portées et l'idée de relief et de strates verticales - ils donnent des exemples de boutons flat : https://material.io/design/material-theming/overview.html#material-theming Donc ça me semble pas être un horizon indépassable :p Concernant la couleur de base, à un moment j'hésitais à partir sur la couleur de l'utilisateur, la version claire. D'ailleurs vous noterez que c'est celle utilisée pour les boutons des formulaires, comme `.boutons` a déjà un fond de couleur claire j'ai fait une exception pour eux. Mais c'est bien des boutons de base, pas la variante `.principal`. Mais bon, j'étais pas convaincu, je préfèrerais quand même arriver à faire fonctionner le gris clair dans toutes les situations. Dans Bootstrap, Semantic-ui et cie, les boutons de base sont également gris clairs. Pour SVP je vais poursuivre dans les tickets liés du coup, sinon on va s'éparpiller. Juste `marcimat, le truc que je propose c'est ni plus ni moins que la maquette de rasta. C'est même moins d'ailleurs. Et j'ai rien de spécial à ajouter en plus.
Owner

Bon, reprenons. Ça semble presque y être mais les derniers réglages sont les plus ardus.

Le dernier point retord pour moi, c'est de faire en sorte que les boutons fonctionnent dans tous les contextes, c.a.d qu'ils soient lisibles quelque soit le fond de couleur de leur parent.

Dans l'image ci-dessous j'ai fait quelques ajustements, et testé avec la plupart des fonds de couleurs utilisés dans le privé.
Pour référence, le 4 c'est #ENV{claire} et le 5 c'est #ENV{foncee}. Les autres sont des ajustements avec |couleur_eclaircir et |couleur_foncer.

  • J'ai ajouté une très légère bordure en bas et ça aide à démarquer les boutons. Donc ok pour moi pour cette prop.
  • Pour les .secondaire le texte prend la couleur de la bordure, je trouve ça plus sympatoche
  • Ensuite pour le gris de base, j'ai mis une couleur transparente afin que ça s'adapte au fond du parent. Ça fonctionne bien sur les couleurs claires (1 à 4). En gardant le gris initial, le 3 et le 4 seraient à peine visibles. Donc avec la couleur transparente, ça évite d'avoir à faire des exceptions.
  • Et donc on en vient aux fonds sombres : dans ce cas là je pense pas qu'on puisse avoir un truc qui s'adapte à tous les cas. À mon avis il faudrait ajouter dans le HTML une variante "inverse" ou autre pour dire "ce bouton est sur un fond sombre". Le bouton de base et la variante .secondaire deviendraient blancs, les .principal peut rester tel quel à priori.
  • Enfin pour la variante .principal, il vaut mieux éviter de reprendre la couleur #ENV{foncee} telle quelle, il faut légèrement augmenter la saturation et la luminosité.

Bon, reprenons. Ça semble presque y être mais les derniers réglages sont les plus ardus. Le dernier point retord pour moi, c'est de faire en sorte que les boutons fonctionnent dans tous les contextes, c.a.d qu'ils soient lisibles quelque soit le fond de couleur de leur parent. Dans l'image ci-dessous j'ai fait quelques ajustements, et testé avec la plupart des fonds de couleurs utilisés dans le privé. Pour référence, le 4 c'est `#ENV{claire}` et le 5 c'est `#ENV{foncee}`. Les autres sont des ajustements avec `|couleur_eclaircir` et `|couleur_foncer`. * J'ai ajouté une très légère bordure en bas et ça aide à démarquer les boutons. Donc ok pour moi pour cette prop. * Pour les `.secondaire` le texte prend la couleur de la bordure, je trouve ça plus sympatoche * Ensuite pour le gris de base, j'ai mis une couleur transparente afin que ça s'adapte au fond du parent. Ça fonctionne bien sur les couleurs claires (1 à 4). En gardant le gris initial, le 3 et le 4 seraient à peine visibles. Donc avec la couleur transparente, ça évite d'avoir à faire des exceptions. * Et donc on en vient aux fonds sombres : dans ce cas là je pense pas qu'on puisse avoir un truc qui s'adapte à tous les cas. À mon avis il faudrait ajouter dans le HTML une variante "inverse" ou autre pour dire "ce bouton est sur un fond sombre". Le bouton de base et la variante `.secondaire` deviendraient blancs, les `.principal` peut rester tel quel à priori. * Enfin pour la variante `.principal`, il vaut mieux éviter de reprendre la couleur `#ENV{foncee}` telle quelle, il faut légèrement augmenter la saturation et la luminosité. ![](/redmine/1217/4562_boutons_fonds.png)
Poster
Owner

C’est super nice cette capture.

Je suis juste suspicieux sur le contraste de texte sur background de :

  • 3.gris (le gauche) un peu
  • 4.gris (surtout)
  • et 4.transparent (le droit)

Désolé je sais pas à quelles classes ça correspond.

On en a beaucoup des fonds en #ENV{foncee} avec des boutons actuellement ?
Les pieds de formulaires on est d’accord que c’est le (3) (claire).

C’est super nice cette capture. Je suis juste suspicieux sur le contraste de texte sur background de : - 3.gris (le gauche) un peu + 4.gris (surtout) + et 4.transparent (le droit) Désolé je sais pas à quelles classes ça correspond. On en a beaucoup des fonds en `#ENV{foncee}` avec des boutons actuellement ? Les pieds de formulaires on est d’accord que c’est le (3) (claire).

c'est carrément mieux, c'est super !

peut-être lancer le test de contrast, comme avec l'extension Tota11y

c'est carrément mieux, c'est super ! peut-être lancer le test de contrast, comme avec l'extension Tota11y

Tiens je vois passer ça aujourd'hui à propos de l'accessibilité/affordance des boutons :
https://seenthis.net/messages/882961

Windows et le Web en 2020 sont terribles visuellement pour ces personnes.

À quoi ressemble un bouton par exemple ? Bah : 🤷‍♀️.
Parfois il y a une bordure, parfois pas, parfois le texte est gras, parfois pas, parfois le curseur change, parfois pas.

Conséquence directe : il est difficile/impossible pour elles d’assimiler ce qui est cliquable ou ne l’est pas.
Elles tentent de cliquer sur tout, et ne comprennent pas ce qu’elles font. Et c’est normal.

Tiens je vois passer ça aujourd'hui à propos de l'accessibilité/affordance des boutons : https://seenthis.net/messages/882961 > Windows et le Web en 2020 sont terribles visuellement pour ces personnes. > > À quoi ressemble un bouton par exemple ? Bah : 🤷‍♀️. > Parfois il y a une bordure, parfois pas, parfois le texte est gras, parfois pas, parfois le curseur change, parfois pas. > > Conséquence directe : il est difficile/impossible pour elles d’assimiler ce qui est cliquable ou ne l’est pas. > Elles tentent de cliquer sur tout, et ne comprennent pas ce qu’elles font. Et c’est normal.
Owner

On est bons là dessus non ? On peut fermer le ticket ?

On est bons là dessus non ? On peut fermer le ticket ?
Owner

On n'y est pas encore, il reste des ajustements à faire.
Et je me pose encore des questions sur les icônes, j'elaborerai dans un autre commentaire.

On n'y est pas encore, il reste des ajustements à faire. Et je me pose encore des questions sur les icônes, j'elaborerai dans un autre commentaire.
Owner

Ok, no hurry :)

Ok, no hurry :)
Owner

Allez je viens jouer ici aussi :)

2 remarques :

  • les classes des boutons étant notamment dans les formulaires, on va les retrouver utilisées dans les parties publiques des sites. Et du coup je pense que les classes de variantes (.add, .del....) sont beaucoup trop génériques et on va se prendre dans la tronche des conflits avec l'un ou l'autre framework ou même avec des css personalisées. Il faudrait donc prefixer toutes les variantes de classes par bouton, ce qui donnerait par exemple class="bouton bouton-add". C'est la bonne pratique utilisée par tous les framework
  • il nous manque des variantes de taille de bouton, comme .bouton-sm et bouton-lg. Cas d'usage typique : le bouton de changement de langue sur les articles avec traduction, qui était un bouton avec une icone 12px car petit bouton, et maintenant quoi qu'on y mette il est gros avec plein de padding
Allez je viens jouer ici aussi :) 2 remarques : - les classes des boutons étant notamment dans les formulaires, on va les retrouver utilisées dans les parties publiques des sites. Et du coup je pense que les classes de variantes (`.add`, `.del`....) sont beaucoup trop génériques et on va se prendre dans la tronche des conflits avec l'un ou l'autre framework ou même avec des css personalisées. Il faudrait donc prefixer toutes les variantes de classes par `bouton`, ce qui donnerait par exemple `class="bouton bouton-add"`. C'est la bonne pratique utilisée par tous les framework - il nous manque des variantes de taille de bouton, comme `.bouton-sm` et `bouton-lg`. Cas d'usage typique : le bouton de changement de langue sur les articles avec traduction, qui était un bouton avec une icone 12px car petit bouton, et maintenant quoi qu'on y mette il est gros avec plein de padding
Owner

Il faudrait donc prefixer toutes les variantes de classes par bouton, ce qui donnerait par exemple class="bouton bouton-add"

Oui je me faisais la même réflexion.
Par contre pour le même prix, autant faire du BEM je pense, ça ne mange pas de pain : bouton bouton_add.

il nous manque des variantes de taille de bouton

Non ça y est déjà, cf. doc dans le plugin dev.

> Il faudrait donc prefixer toutes les variantes de classes par bouton, ce qui donnerait par exemple class="bouton bouton-add" Oui je me faisais la même réflexion. Par contre pour le même prix, autant faire du BEM je pense, ça ne mange pas de pain : `bouton bouton_add`. > il nous manque des variantes de taille de bouton Non ça y est déjà, cf. doc dans le plugin dev.
Owner

Bon, reprenons, il reste un dernier tour de manivelle à faire.
En résumé, ça fait 3 points à traiter :

  1. Préfixer les variantes pour éviter les téléscopages comme suggéré par cedric

  2. Ajustements visuels pour améliorer l'affordance, le contraste et cie, cf. image dans le commentaire "#53":https://core.spip.net/issues/4562#note-53
    Pour arriver au plus proche de cette image, il manque une poignée de fonctions dans le traitement des couleurs : on a une fonction pour mettre une valeur de saturation, mais pas pour saturer ou désaturer relativement à la valeur d'origine (alors que pour la luminosité, on a bien le tryptique). Et une dernière pour changer l'opacité serait pas mal non plus.
    Je vais faire une PR à part pour ça (ça concerne Spip et le plugin dist à la fois).

  3. Enfin, une dernière chose qui me chiffone sur les icônes : je pense qu'il faudrait passer dès maintenant à des icônes symboliques plutôt que reprendre telles quelles les icônes de couleurs utilisées pour les filtres |icone_horizontale et |icone_verticale.
    Les boutons ont parfois des fonds de couleur, et dans certains les icônes sont difficile à dicerner, et dans l'ensemble ça fait un peu chargé.
    Attention je parle bien juste des boutons, on touche pas aux |icone_horizontale car elles ont toujours un fond blanc ou clair, et pour elles l'icône est l'élément principal donc c'est normal qu'elle soit bien visible.
    En revanche pour les boutons, les icônes sont optionnelles, elles ne sont là qu'en « support », donc ça me semble mieux qu'elles soient un peu en retrait.
    À noter que les variantes symboliques sont déjà visibles en blanc au survol, il suffit juste d'en faire des variantes foncées quoi.
    Nb : s'il y a une refonte de l'interface un jour, nulle doute qu'il y aura un truc un peu plus rôdé pour ces icônes symboliques (via une police fontface ou autre), et donc en attendant au moins on sera déjà alignés visuellement.

Et ma foi avec ça, ça devrait le faire.
J'hésitais : je continue dans une branche à part ou je commite dans le lard ?

Bon, reprenons, il reste un dernier tour de manivelle à faire. En résumé, ça fait 3 points à traiter : 1) Préfixer les variantes pour éviter les téléscopages comme suggéré par cedric 2) Ajustements visuels pour améliorer l'affordance, le contraste et cie, cf. image dans le commentaire "#53":https://core.spip.net/issues/4562#note-53 Pour arriver au plus proche de cette image, il manque une poignée de fonctions dans le traitement des couleurs : on a une fonction pour mettre une valeur de saturation, mais pas pour saturer ou désaturer relativement à la valeur d'origine (alors que pour la luminosité, on a bien le tryptique). Et une dernière pour changer l'opacité serait pas mal non plus. Je vais faire une PR à part pour ça (ça concerne Spip et le plugin dist à la fois). 3) Enfin, une dernière chose qui me chiffone sur les icônes : je pense qu'il faudrait passer dès maintenant à des icônes symboliques plutôt que reprendre telles quelles les icônes de couleurs utilisées pour les filtres |icone_horizontale et |icone_verticale. Les boutons ont parfois des fonds de couleur, et dans certains les icônes sont difficile à dicerner, et dans l'ensemble ça fait un peu chargé. Attention je parle bien juste des boutons, on touche pas aux |icone_horizontale car elles ont toujours un fond blanc ou clair, et pour elles l'icône est l'élément principal donc c'est normal qu'elle soit bien visible. En revanche pour les boutons, les icônes sont optionnelles, elles ne sont là qu'en « support », donc ça me semble mieux qu'elles soient un peu en retrait. À noter que les variantes symboliques sont déjà visibles en blanc au survol, il suffit juste d'en faire des variantes foncées quoi. Nb : s'il y a une refonte de l'interface un jour, nulle doute qu'il y aura un truc un peu plus rôdé pour ces icônes symboliques (via une police fontface ou autre), et donc en attendant au moins on sera déjà alignés visuellement. Et ma foi avec ça, ça devrait le faire. J'hésitais : je continue dans une branche à part ou je commite dans le lard ?
Owner

Bon je vais essayer de boucler cette histoire de boutons avant la release de la beta.

Le dernier point qui me bloque, c'est les icônes, je crois que je suis parti sur une mauvaise piste :-/
Utiliser des classes pour ajouter des icônes à certains boutons, ça me semble finalement une fausse bonne idée :

  • En CSS, c'est un peu casse-gueule, compliqué à gérer et à maintenir : des fois c'est sous la forme d'un pseudo-élément :before, et quand on peut pas il faut utiliser un background-image (pour les inputs). Vraiment, ça complique considérablement la CSS.
  • À l'utilisation ça fait beaucoup de classes à se souvenir, et ça devient assez verbeux : class="bouton bouton_principal bouton_add"

Mais il est encore temps de rectifier le tir, vu que c'est pas encore officialisé et donc très peu utilisé.
Je crois que la bonne approche, c'est de dire : quand on veut une icône, on la met dans le HTML.
C'est la solution retenue dans tous les frameworks et je comprends maintenant pourquoi :p

Pour faciliter l'utilisation je propose d'introduire une nouvelle balise #ICONE_SPIP{id, taille} (ou un autre nom, go nomenklatura), ce qui donnerait ceci à l'utilisation :

<a class="bouton" href="…">#ICONE_SPIP{add} Mon super bouton</a>

[(#BOUTON_ACTION{#ICONE_SPIP{add} Mon super bouton, …})]

Qui produirait ce html :

<svg class="icone-spip icone-spip_add" width="16" height="16" fill="currentColor">
  <use xlink:href="prive/themes/spip/images/icones-spip.svg#add"/>
</svg>

Exactement comme c'est fait dans "Bootstrap":https://icons.getbootstrap.com/#usage

Avantages :

  • Simplifie à mort la CSS des boutons
  • Un unique fichier à charger et à maintenir, spécifique aux icônes symboliques [1]
  • On hérite automatiquement de la couleur du texte
  • Taille équivalente à 1em par défaut (16px)
  • Ça peut être utilisé en dehors des boutons

Des avis ? Je pars là-dessus ?


[1] C'est à dire que la balise servirait uniquement à utiliser des icônes symboliques, pas n'importe quelle image se trouvant dans themes/spip/images.

Bon je vais essayer de boucler cette histoire de boutons avant la release de la beta. Le dernier point qui me bloque, c'est les icônes, je crois que je suis parti sur une mauvaise piste :-/ Utiliser des classes pour ajouter des icônes à certains boutons, ça me semble finalement une fausse bonne idée : * En CSS, c'est un peu casse-gueule, compliqué à gérer et à maintenir : des fois c'est sous la forme d'un pseudo-élément :before, et quand on peut pas il faut utiliser un background-image (pour les inputs). Vraiment, ça complique considérablement la CSS. * À l'utilisation ça fait beaucoup de classes à se souvenir, et ça devient assez verbeux : `class="bouton bouton_principal bouton_add"` Mais il est encore temps de rectifier le tir, vu que c'est pas encore officialisé et donc très peu utilisé. Je crois que la bonne approche, c'est de dire : quand on veut une icône, on la met dans le HTML. C'est la solution retenue dans tous les frameworks et je comprends maintenant pourquoi :p Pour faciliter l'utilisation je propose d'introduire une nouvelle balise #ICONE_SPIP{id, taille} (ou un autre nom, go nomenklatura), ce qui donnerait ceci à l'utilisation : ``` <a class="bouton" href="…">#ICONE_SPIP{add} Mon super bouton</a> [(#BOUTON_ACTION{#ICONE_SPIP{add} Mon super bouton, …})] ``` Qui produirait ce html : ``` <svg class="icone-spip icone-spip_add" width="16" height="16" fill="currentColor"> <use xlink:href="prive/themes/spip/images/icones-spip.svg#add"/> </svg> ``` Exactement comme c'est fait dans "Bootstrap":https://icons.getbootstrap.com/#usage Avantages : * Simplifie à mort la CSS des boutons * Un unique fichier à charger et à maintenir, spécifique aux icônes symboliques [1] * On hérite automatiquement de la couleur du texte * Taille équivalente à 1em par défaut (16px) * Ça peut être utilisé en dehors des boutons Des avis ? Je pars là-dessus ? ---------------------------- [1] C'est à dire que la balise servirait uniquement à utiliser des icônes symboliques, pas n'importe quelle image se trouvant dans themes/spip/images.
Owner

Pas d'avis tranché sur une première lecture, à part ce point :

des fois c'est sous la forme d'un pseudo-élément :before, et quand on peut pas il faut utiliser un background-image (pour les inputs)

Justement, #ICONE_SPIP ne sera pas utilisable avec un <input type="submit">, qui ne peut contenir qu'une value texte.
Ça veut donc dire supprimer tous ces input et les remplacer systématiquement par des button partout dans les plugins.

Sinon, une pétouille mais il manque focusable="false" et aria-hidden="true" dans ton svg.

Pas d'avis tranché sur une première lecture, à part ce point : > des fois c'est sous la forme d'un pseudo-élément :before, et quand on peut pas il faut utiliser un background-image (pour les inputs) Justement, #ICONE_SPIP ne sera pas utilisable avec un `<input type="submit">`, qui ne peut contenir qu'une value texte. Ça veut donc dire supprimer tous ces input et les remplacer systématiquement par des button partout dans les plugins. Sinon, une pétouille mais il manque focusable="false" et aria-hidden="true" dans ton svg.

Avis mitigé pour moi :

  • dans tous les frameworks c'est plutôt les deux (voire trois, voire quatre !), càd qu'on peut mettre une balise et on peut bien entendu aussi ajouter une icône à un truc existant, cf toutes les méthodes d'insertion listées ici : https://icons.getbootstrap.com/
  • et donc il faut plusieurs méthodes, justement pour pouvoir l'insérer aussi sur des éléments où on ne maitrise pas le HTML ou si on peut pas demander à tout le monde de rajouter une icône en dur dans leur HTML, je rappelle que tout doit valoir pour les plugins etc, pas juste le core, donc dans les plugins on doit juste pouvoir ajouter une classe qui sera toujours la même, et qui ne changera pas même si on change le thème d'icône
  • donc oui pour moi on doit dépendre le moins possible du HTML, dans le HTML on dit avec des classes "ça c'est un bouton pour supprimer", "ça c'est un bouton qui permet d'éditer", on donne un sens, et ensuite c'est de la déco graphique, on ne doit pas changer le HTML si jamais on veut styler autrement
Avis mitigé pour moi : - dans tous les frameworks c'est plutôt *les deux* (voire trois, voire quatre !), càd qu'on peut mettre une balise *et* on peut bien entendu aussi ajouter une icône à un truc existant, cf toutes les méthodes d'insertion listées ici : https://icons.getbootstrap.com/ - et donc il faut plusieurs méthodes, justement pour pouvoir l'insérer aussi sur des éléments où on ne maitrise pas le HTML ou si on peut pas demander à tout le monde de rajouter une icône en dur dans leur HTML, je rappelle que tout doit valoir pour les plugins etc, pas juste le core, donc dans les plugins on doit juste pouvoir ajouter une classe qui sera toujours la même, et qui ne changera pas même si on change le thème d'icône - donc oui pour moi on doit dépendre le moins possible du HTML, dans le HTML on dit avec des classes "ça c'est un bouton pour supprimer", "ça c'est un bouton qui permet d'éditer", on donne un sens, et ensuite c'est de la déco graphique, on ne doit pas changer le HTML si jamais on veut styler autrement
Owner

J'avais dit "pas tranché" parce que j'avais en tête aussi tes remarques : l'écosystème des plugins (mais bon, ils n'utilisent pas encore les nouvelles classes, et sont donc à modifier de toute façon), et ne pas dépendre du markup html (mais bon, on dépend quand même de classes dans le html).
Par contre, deux méthodes parallèles c'est encore plus de boulot de maintenance : on ne cale pas une icone de la même façon si elle est en :before ou si elle est inline...

Bref, toujours pas d'avis tranché, si ça peut aider... ¯_(ツ)_/¯

J'avais dit "pas tranché" parce que j'avais en tête aussi tes remarques : l'écosystème des plugins (mais bon, ils n'utilisent pas encore les nouvelles classes, et sont donc à modifier de toute façon), et ne pas dépendre du markup html (mais bon, on dépend quand même de classes dans le html). Par contre, deux méthodes parallèles c'est encore plus de boulot de maintenance : on ne cale pas une icone de la même façon si elle est en :before ou si elle est inline... Bref, toujours pas d'avis tranché, si ça peut aider... ¯\_(ツ)_/¯
Owner

dans tous les frameworks c'est plutôt les deux (voire trois, voire quatre !), càd qu'on peut mettre une balise et on peut bien entendu aussi ajouter une icône à un truc existant,

Ah mais non, dans Bootstrap les icônes c'est uniquement des éléments dans le HTML, soit direct un svg ou un img, soit via une font-face avec <i class="bi bi-truc">. C'est juste des variantes sur le même principe.

Leur classe .bi elle est prévue uniquement pour leur truc à base de font-face, elle ne sert pas à ajouter une icône à n'importe quel élément en général.
Essayer de faire ça purement en CSS c'est rédibitoirement compliqué, sans avoir aucune garantie du résultat selon l'élément où c'est appliqué.

Sur github ils avaient un post de blog pour expliquer pourquoi ils avaient décidé de passer à des icônes sous forme de svg embarqué aussi (ni de font-face, ni de truc 100% en CSS).
edit : làhttps://github.blog/2016-02-22-delivering-octicons-with-svg/ *

je rappelle que tout doit valoir pour les plugins etc, pas juste le core, donc dans les plugins on doit juste pouvoir ajouter une classe qui sera toujours la même, et qui ne changera pas même si on change le thème d'icône

Je vois pas trop où tu veux en venir. Si tu peux ajouter une classe "bouton_supprimer" dans ton HTML ça veut dire que tu peux aussi ajouter une balise #ICONE{supprimer}, t'as bien la main dessus. Le 1er paramètre a exactement le même sens que la classe, et il n'est pas amené à changer au fil du temps. Les icônes derrière, peut-être, mais pas le paramètre de la balise.

Le seul problème que je vois c'est que ça peut se retrouver dans des formulaires ou des squelettes utilisés à la fois dans le public et le privé.
Dans le privé on veut utiliser forcément tel jeu d'icônes, dans le public ça doit pouvoir être surchargeable.

Justement, #ICONE_SPIP ne sera pas utilisable avec un , qui ne peut contenir qu'une value texte.

Tant pis j'ai envie de dire :p
Faire ça en CSS comme actuellement c'est vraiment bancal de toute façon.
Sinon ça peut pousser à remplacer par des buttons oui.

Pour les attributs d'accessibilité oui, c'est bien sûr à intégrer.

> dans tous les frameworks c'est plutôt les deux (voire trois, voire quatre !), càd qu'on peut mettre une balise et on peut bien entendu aussi ajouter une icône à un truc existant, Ah mais non, dans Bootstrap les icônes c'est uniquement des éléments dans le HTML, soit direct un svg ou un img, soit via une font-face avec `<i class="bi bi-truc">`. C'est juste des variantes sur le même principe. Leur classe `.bi` elle est prévue uniquement pour leur truc à base de font-face, elle ne sert pas à ajouter une icône à n'importe quel élément en général. Essayer de faire ça purement en CSS c'est rédibitoirement compliqué, sans avoir aucune garantie du résultat selon l'élément où c'est appliqué. Sur github ils avaient un post de blog pour expliquer pourquoi ils avaient décidé de passer à des icônes sous forme de svg embarqué aussi (ni de font-face, ni de truc 100% en CSS). _edit : là_ → https://github.blog/2016-02-22-delivering-octicons-with-svg/ * > je rappelle que tout doit valoir pour les plugins etc, pas juste le core, donc dans les plugins on doit juste pouvoir ajouter une classe qui sera toujours la même, et qui ne changera pas même si on change le thème d'icône Je vois pas trop où tu veux en venir. Si tu peux ajouter une classe "bouton_supprimer" dans ton HTML ça veut dire que tu peux aussi ajouter une balise #ICONE{supprimer}, t'as bien la main dessus. Le 1er paramètre a exactement le même sens que la classe, et il n'est pas amené à changer au fil du temps. Les icônes derrière, peut-être, mais pas le paramètre de la balise. Le seul problème que je vois c'est que ça peut se retrouver dans des formulaires ou des squelettes utilisés à la fois dans le public et le privé. Dans le privé on veut utiliser forcément tel jeu d'icônes, dans le public ça doit pouvoir être surchargeable. > Justement, #ICONE_SPIP ne sera pas utilisable avec un <input type="submit">, qui ne peut contenir qu'une value texte. Tant pis j'ai envie de dire :p Faire ça en CSS comme actuellement c'est vraiment bancal de toute façon. Sinon ça peut pousser à remplacer par des buttons oui. Pour les attributs d'accessibilité oui, c'est bien sûr à intégrer.
Owner

Remarque : cette balise #ICONE_SPIP me fait penser au plugin https://git.spip.net/spip-contrib-extensions/fontawesome/

Remarque : cette balise #ICONE_SPIP me fait penser au plugin https://git.spip.net/spip-contrib-extensions/fontawesome/
Owner

`b_b : dans l'idée c'est ça oui. Je crois me souvenir qu'il y a pareil dans le plugin Bootstrap aussi.
Mais là il s'agirait d'un jeu d'icône réduit, destiné avant tout à l'utilisation dans le privé. Et ne dépendant d'aucune ressource à charger (css ou fontface).

`b_b : dans l'idée c'est ça oui. Je crois me souvenir qu'il y a pareil dans le plugin Bootstrap aussi. Mais là il s'agirait d'un jeu d'icône réduit, destiné avant tout à l'utilisation dans le privé. Et ne dépendant d'aucune ressource à charger (css ou fontface).
Owner

ps : mais ça nous dit pas ce que t'en penses :p

ps : mais ça nous dit pas ce que t'en penses :p

Je vois pas trop où tu veux en venir. Si tu peux ajouter une classe "bouton_supprimer" dans ton HTML ça veut dire que tu peux aussi ajouter une balise #ICONE{supprimer}, t'as bien la main dessus. Le 1er paramètre a exactement le même sens que la classe, et il n'est pas amené à changer au fil du temps. Les icônes derrière, peut-être, mais pas le paramètre de la balise.

Bah non, aucun rapport : une classe CSS, si on parle bien d'une classe qui n'est pas "icone_XXX", mais bien des classes de variante pour dire "ceci est un bouton de suppression", "ceci est un bouton d'édition d'un contenu", "ceci est un bouton de sauvegarde/d'enregistrement"… tout ça ce sont des classes qui donnent juste un sens à ce bouton, sans du tout préjuger de comment on veut le styler.

Alors que #ICONE{truc} ça signifie uniquement : je veux insérer l'icône de ce nom.

En ce moment tous les gros acteurs se lancent dans le HTML non sémantiques, justement parce que désormais 90% des apps sont générées à base de morceaux autonomes (react etc) qui mélangent contenus et choix graphiques. D'ailleurs même avant les "css utilitaires", tous les gros frameworks poussaient aussi à ça, en obligeant à mettre des "col-4" etc dans le HTML, ce qui inscrit en dur le layout sans pouvoir le changer dans un thème. Je ne trouve pas que ce soit forcément un exemple à suivre. Mon impression est qu'on s'éloigne de plus en plus de la conception de base de la séparation HTML/CSS. Par exemple si on décide ergonomiquement que dans l'admin "tous les boutons pour le sens XXX et YYY doivent avoir leur icône" et puis plus tard à l'utilisation on s'aperçoit que c'est trop lourd et on décide comme bonne pratique "non en fait seulement les boutons pour le sens XXX doivent avoir un picto, mais pas YYY" : alors il faudra aller les retirer partout où on ne les veut plus à la fois core mais tous les plugins. Alors que c'est débile, c'est juste un choix graphique et ergonomique à un instant T. Alors ça dépend des utilisations, parfois c'est logique par rapport à la conception de l'appli (react etc, et encore, on pourrait arguer que justement elles sont parfois mal conçues).

Le seul problème que je vois c'est que ça peut se retrouver dans des formulaires ou des squelettes utilisés à la fois dans le public et le privé.
Dans le privé on veut utiliser forcément tel jeu d'icônes, dans le public ça doit pouvoir être surchargeable.

Au moins pour tous les formulaires, il faut d'après moi considérer qu'ils ne doivent pas être propre à l'admin de SPIP. Cette admin les utilise, c'est une interface par défaut, fournie pour gérer ses contenus. Mais on doit pouvoir les utiliser facilement n'importe où.

Et c'est un bon exemple de la séparation : ajouter tel picto, c'est un choix de décoration propre à l'admin, parce que dans ce contexte là on veut ajouter un picto à tel endroit. Mais ailleurs, dans le site, etc, peut-être qu'on veut styler autrement. Pas juste changer l'icône (ce qui doit déjà être possible aussi), mais c'est d'autres choix graphiques. C'est bien pour ça que le HTML doit rester neutre et sémantique normalement.

> Je vois pas trop où tu veux en venir. Si tu peux ajouter une classe "bouton_supprimer" dans ton HTML ça veut dire que tu peux aussi ajouter une balise #ICONE{supprimer}, t'as bien la main dessus. Le 1er paramètre a exactement le même sens que la classe, et il n'est pas amené à changer au fil du temps. Les icônes derrière, peut-être, mais pas le paramètre de la balise. Bah non, aucun rapport : une classe CSS, si on parle bien d'une classe qui n'est *pas* "icone_XXX", mais bien des classes de variante pour dire "ceci est un bouton de suppression", "ceci est un bouton d'édition d'un contenu", "ceci est un bouton de sauvegarde/d'enregistrement"… tout ça ce sont des classes qui donnent juste un *sens* à ce bouton, sans du tout préjuger de comment on veut le styler. Alors que #ICONE{truc} ça signifie uniquement : je veux insérer l'icône de ce nom. En ce moment tous les gros acteurs se lancent dans le HTML non sémantiques, justement parce que désormais 90% des apps sont générées à base de morceaux autonomes (react etc) qui mélangent contenus et choix graphiques. D'ailleurs même avant les "css utilitaires", tous les gros frameworks poussaient aussi à ça, en obligeant à mettre des "col-4" etc dans le HTML, ce qui inscrit en dur le layout sans pouvoir le changer dans un thème. Je ne trouve pas que ce soit forcément un exemple à suivre. Mon impression est qu'on s'éloigne de plus en plus de la conception de base de la séparation HTML/CSS. Par exemple si on décide ergonomiquement que dans l'admin "tous les boutons pour le sens XXX et YYY doivent avoir leur icône" et puis plus tard à l'utilisation on s'aperçoit que c'est trop lourd et on décide comme bonne pratique "non en fait seulement les boutons pour le sens XXX doivent avoir un picto, mais pas YYY" : alors il faudra aller les retirer partout où on ne les veut plus à la fois core mais tous les plugins. Alors que c'est débile, c'est juste un choix graphique et ergonomique à un instant T. Alors ça dépend des utilisations, parfois c'est logique par rapport à la conception de l'appli (react etc, et encore, on pourrait arguer que justement elles sont parfois mal conçues). > Le seul problème que je vois c'est que ça peut se retrouver dans des formulaires ou des squelettes utilisés à la fois dans le public et le privé. > Dans le privé on veut utiliser forcément tel jeu d'icônes, dans le public ça doit pouvoir être surchargeable. Au moins pour tous les formulaires, il faut d'après moi considérer qu'ils ne doivent pas être propre à l'admin de SPIP. Cette admin les utilise, c'est une interface par défaut, fournie pour gérer ses contenus. Mais on doit pouvoir les utiliser facilement n'importe où. Et c'est un bon exemple de la séparation : ajouter tel picto, c'est un choix de décoration propre à l'admin, parce que dans ce contexte là on veut ajouter un picto à tel endroit. Mais ailleurs, dans le site, etc, peut-être qu'on veut styler autrement. Pas juste changer l'icône (ce qui doit déjà être possible aussi), mais c'est d'autres choix graphiques. C'est bien pour ça que le HTML doit rester neutre et sémantique normalement.
Owner

Les grands principes de séparation entre la forme et le contenu, oui ok d'accord.

Mais t'as bien vu que l'objet de cette proposition, c'est justement d'accepter de faire un compromis pour simplifier la vie de tout le monde : à la fois pour maintenir le truc et à la fois quand on veut les utiliser dans le core et les plugins.
Le constat de départ je rappelle, c'est qu'actuellement c'est bien des classes sémantiques-tout-ça, mais au prix de circonvolutions hypers lourdes dans le css (t'as jeté un coup d'oeil à boutons.css ?).

Si on est pas content des quelques icônes qui peuvent se ballader d'office dans certains formulaires ou bouts de squelettes, on règle ça en 1 ligne de CSS hein : .icone-spip { display: none }
Ou même si on veut les garder et les surcharger : .icone-spip svg { display: none } et voilà.
Ça me semble pas un très gros prix à payer.

Les grands principes de séparation entre la forme et le contenu, oui ok d'accord. Mais t'as bien vu que l'objet de cette proposition, c'est justement d'accepter de faire un compromis pour simplifier la vie de tout le monde : à la fois pour maintenir le truc et à la fois quand on veut les utiliser dans le core et les plugins. Le constat de départ je rappelle, c'est qu'actuellement c'est bien des classes sémantiques-tout-ça, mais au prix de circonvolutions hypers lourdes dans le css (t'as jeté un coup d'oeil à boutons.css ?). Si on est pas content des quelques icônes qui peuvent se ballader d'office dans certains formulaires ou bouts de squelettes, on règle ça en 1 ligne de CSS hein : `.icone-spip { display: none }` Ou même si on veut les garder et les surcharger : `.icone-spip svg { display: none }` et voilà. Ça me semble pas un très gros prix à payer.
Owner

tcharlss 🐽 a écrit :

ps : mais ça nous dit pas ce que t'en penses :p

Je n'en pense pas grand chose, désolé, je pense que vous êtes bien assez de 4 personnes pour traiter le ticket :)

tcharlss 🐽 a écrit : > ps : mais ça nous dit pas ce que t'en penses :p Je n'en pense pas grand chose, désolé, je pense que vous êtes bien assez de 4 personnes pour traiter le ticket :)
Owner

Bon bon bon, on a pas mal réfléchi au sujet avec rastapopoulos, et je crois qu'on est arrivé à une solution satisfaisante.
En tout cas une solution qui répond complètement aux problèmes et besoins soulevés dans ce ticket, en ce qui me concerne.

Le problème était de ne traiter des icônes que sous l'angle d'une utilisation dans des boutons, de ne le faire qu'à moitié en proposant un jeu d'icônes très restreint, et avec des icônes pas toutes prévues pour cette utilisation qui plus est.

Dans l'immédiat, pour clôturer ce ticket au plus vite, il s'agirait de faire ça :

  • dans le CSS, retirer complètement les variantes de boutons avec icônes : .bouton_add, .bouton_supprimer, etc. (ça sera fait différemment et mieux).
  • renommer la classe .bouton en .btn : c'est moins verbeux et on comprend aussi bien.
  • préfixer les variantes génériques qui restent : .btn_mini au lieu de .btn mini, etc.
  • finir les derniers petits ajustement visuels.

Avec ça le ticket pourra enfin être fermé.

Mais alors comment fait-on pour avoir des icônes dans les boutons ?
C'est l'étape suivante.

Des icônes

On s'est dit, tant qu'à faire, autant proposer tout de suite un jeu complet d'icônes symboliques.

Les besoins sont multiples pour pleins d'éléments d'interface, dans les plugins et dans le core : plier/déplier des trucs, dupliquer un contenu, afficher un menu, remonter dans la hiérarchie, etc., etc. (je fais vite).
Et chacun doit réimplémenter ça un peu à sa sauce.

On reprendrait 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.
Il y a plusieurs choix de jeux d'icônes libres : "Bootstrap-icons":https://icons.getbootstrap.com/#usage, "Octicon":https://github.com/primer/octicons, "Material":https://material.io/resources/icons/, "Entypo":https://github.com/hypermodules/entypo, etc.

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

1. Des classes

Quand il s'agit d'icônes purement décoratives, des classes que l'on peut ajouter à n'importe quel élément inline.
Pour éviter les conflits, on propose la contraption de spip + icon = spicon.
Cette solution utilise une fontface, l'icône hérite de la taille et de la couleur du texte.

Pour les boutons, même principe : la classe signifie « ajoute une icône dans cet élément »

Exemples :

<button class="spicon_menu">Ouvrir le menu</button>
<i class="spicon_truc"></i> Du texte
<h2 class="titrem spicon_machin">Mon titre</h2>

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 super balise "#ICON":https://git.spip.net/spip-contrib-extensions/z-core/src/branch/master/zcore_options.php#L166 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 : <icone|icone=truc>

#ICONE{identifiant}
#ICONE{chemin/vers/mon_icone.svg}
#ICONE{#identifiant_autre_set}

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}.

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

Voilà, je crois que c'est tout, rastapopoulos tu complètera si j'ai oublié des trucs.
Peut-être qu'on peut partir sur un nouveau ticket pour ce sujet et la branche dev qui ira avec.

À vous les studios.

Bon bon bon, on a pas mal réfléchi au sujet avec rastapopoulos, et je crois qu'on est arrivé à une solution satisfaisante. En tout cas une solution qui répond complètement aux problèmes et besoins soulevés dans ce ticket, en ce qui me concerne. Le problème était de ne traiter des icônes que sous l'angle d'une utilisation dans des boutons, de ne le faire qu'à moitié en proposant un jeu d'icônes très restreint, et avec des icônes pas toutes prévues pour cette utilisation qui plus est. Dans l'immédiat, pour clôturer ce ticket au plus vite, il s'agirait de faire ça : * dans le CSS, retirer *complètement* les variantes de boutons avec icônes : `.bouton_add`, `.bouton_supprimer`, etc. (ça sera fait différemment et mieux). * renommer la classe `.bouton` en `.btn` : c'est moins verbeux et on comprend aussi bien. * préfixer les variantes génériques qui restent : `.btn_mini` au lieu de `.btn mini`, etc. * finir les derniers petits ajustement visuels. Avec ça le ticket pourra enfin être fermé. Mais alors comment fait-on pour avoir des icônes dans les boutons ? C'est l'étape suivante. ## Des icônes On s'est dit, tant qu'à faire, autant proposer tout de suite un jeu *complet* d'icônes symboliques. Les besoins sont multiples pour pleins d'éléments d'interface, dans les plugins et dans le core : plier/déplier des trucs, dupliquer un contenu, afficher un menu, remonter dans la hiérarchie, etc., etc. (je fais vite). Et chacun doit réimplémenter ça un peu à sa sauce. On reprendrait 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. Il y a plusieurs choix de jeux d'icônes libres : "Bootstrap-icons":https://icons.getbootstrap.com/#usage, "Octicon":https://github.com/primer/octicons, "Material":https://material.io/resources/icons/, "Entypo":https://github.com/hypermodules/entypo, etc. Ces icônes seraient utilisables de 2 façons : ### 1. Des classes Quand il s'agit d'icônes purement décoratives, des classes que l'on peut ajouter à n'importe quel élément inline. Pour éviter les conflits, on propose la contraption de spip + icon = spicon. Cette solution utilise une fontface, l'icône hérite de la taille et de la couleur du texte. Pour les boutons, même principe : la classe signifie « ajoute une icône dans cet élément » Exemples : ``` <button class="spicon_menu">Ouvrir le menu</button> <i class="spicon_truc"></i> Du texte <h2 class="titrem spicon_machin">Mon titre</h2> ``` ### 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 super balise "#ICON":https://git.spip.net/spip-contrib-extensions/z-core/src/branch/master/zcore_options.php#L166 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 : `<icone|icone=truc>` ``` #ICONE{identifiant} #ICONE{chemin/vers/mon_icone.svg} #ICONE{#identifiant_autre_set} ``` ### 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}`. La liste initiale est visible ici : https://demo.hedgedoc.org/3zIXkcFLTVSwV0nKC1_qcA?both Voilà, je crois que c'est tout, rastapopoulos tu complètera si j'ai oublié des trucs. Peut-être qu'on peut partir sur un nouveau ticket pour ce sujet et la branche dev qui ira avec. À vous les studios.

Yep ça me parait bien comme roadmap, on clôture ce ticket en faisant des boutons qui ne font que des boutons, et on ferme. Et on fait un autre ticket et une PR associée spécifiquement dédiés aux pictos (et si on peut avoir ça en 3.3 ça sera grave top moumoute aussi bien pour le core que pour les plugins).

Yep ça me parait bien comme roadmap, on clôture ce ticket en faisant des boutons qui ne font que des boutons, et on ferme. Et on fait un autre ticket et une PR associée spécifiquement dédiés aux pictos (et si on peut avoir ça en 3.3 ça sera grave top moumoute aussi bien pour le core que pour les plugins).
Owner

ah cool ! on va pouvoir faire

<button class="spicon_biere">Buvez en c'est excellent</button>
ah cool ! on va pouvoir faire ``` <button class="spicon_biere">Buvez en c'est excellent</button> ```
Owner

Tant qu'à faire ce refactoring complet en changeant les noms des classes etc, je propose d'en profiter pour remplacer tous les <input type="submit"> qui resteraient par des <button type="submit">

En complément, ce serait cool si ces styles de boutons et ce jeu d'icones étaient utilisables aussi sur le public (mais c'est peut être prévu ?)

Tant qu'à faire ce refactoring complet en changeant les noms des classes etc, je propose d'en profiter pour remplacer tous les `<input type="submit">` qui resteraient par des` <button type="submit">` En complément, ce serait cool si ces styles de boutons et ce jeu d'icones étaient utilisables aussi sur le public (mais c'est peut être prévu ?)
Owner

nicod_ : au minimum la PR mettra un <button> pour les #BOUTON_ACTION
Pour les autres ça me paraît une bonne idée, mais à voir à part peut-être ? Je sais pas si ça peut occasionner des dommages collatéraux.

Pour le public, ça marchera direct avec la balise #ICONE.
Pour les classes .spicon_biere et cie, par défaut ça sera pas visible, il faudra charger les ressources soi-même (la fontface et la css).

`nicod_` : au minimum la PR mettra un `<button>` pour les #BOUTON_ACTION Pour les autres ça me paraît une bonne idée, mais à voir à part peut-être ? Je sais pas si ça peut occasionner des dommages collatéraux. Pour le public, ça marchera direct avec la balise #ICONE. Pour les classes .spicon_biere et cie, par défaut ça sera pas visible, il faudra charger les ressources soi-même (la fontface et la css).

Yep Nico, on se disait bien pareil, au moins pour les BOUTON_ACTION qui sont des formulaires mono-bouton donc ça au moins on est sûr.

Pour les autres formulaires, on se posait justement la question, si ça va rien casser ? Est-ce que le button type="submit" ont bien le même comportement, notamment quand il s'agit d'être pris en compte en tant que "premier bouton submit du formulaire" qui est celui lancé quand on appuie Entrer quand on a le focus dans un champ de saisie ? Si c'est oui sûr sûr, alors on peut aussi remplacer les autres.

Yep Nico, on se disait bien pareil, au moins pour les BOUTON_ACTION qui sont des formulaires mono-bouton donc ça au moins on est sûr. Pour les autres formulaires, on se posait justement la question, si ça va rien casser ? Est-ce que le button type="submit" ont bien le même comportement, notamment quand il s'agit d'être pris en compte en tant que "premier bouton submit du formulaire" qui est celui lancé quand on appuie Entrer quand on a le focus dans un champ de saisie ? Si c'est oui sûr sûr, alors on peut aussi remplacer les autres.
Owner

ça a donc été fini par #156
Statut changé à Fermé

ça a donc été fini par https://git.spip.net/spip/spip/pulls/156 **Statut changé à Fermé**
Sign in to join this conversation.
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.