Des pictos / icônes symboliques pour tout le monde #4727

Je fais un ticket pour la future PR et poser le plan d'action.
C'est la suite de #4562

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

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

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

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

Utilisation

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

1) Des classes .sp-icone

Des classes à ajouter à n'importe quel élément inline quand il s'agit d'icônes purement décoratives.
Ces classes pouvant finir dans squelettes utilisés dans le public, pour éviter les conflits, on propose sp-icone.

Exemples :

<button class="sp-icone_menu">Ouvrir le menu</button>
<h2 class="titrem sp-icone_machin">Mon titre</h2>

2) Une balise #ICONE

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

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

Un modèle correspondant permettra aussi d'inclure des icônes svg dans les textes : <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}.
Cela passerait par un pipeline, donc liste qui peut être complétée selon ses besoins.

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

Ressources privé / public

Cela veut dire 2 ressources à charger :

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

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

Candidats

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

edit: voir aussi https://icones.js.org/

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

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

Je fais un ticket pour la future PR et poser le plan d'action. C'est la suite de #4562 ## Proposition pour intégrer un jeu complet d'icônes symboliques. Les besoins sont multiples pour pleins d'éléments d'interface, dans le core et les plugins : des barres d'outils, des boutons d'actions, etc. Et chacun doit réimplémenter ça un peu à sa sauce, notamment dans le privé. C'est un besoin bien distinct des icônes svg de couleur dont on dispose actuellement dans le privé : on veut des pictos symboliques qui héritent de taille et de la couleur du texte, et issus d'un même set afin d'avoir un style unifié. Cela vient donc en complément. Il s'agit donc de reprendre un jeu d'icônes existant, qu'on n'aura pas à maintenir, optimisé, et qui fournit des icônes cohérentes visuellement, utilisables dans tous les contextes. Cf. plus bas pour une comparaison initiale des candidats possibles. ## Utilisation Ces icônes seraient utilisables de 2 façons : ### 1) Des classes .sp-icone Des classes à ajouter à n'importe quel élément inline quand il s'agit d'icônes purement décoratives. Ces classes pouvant finir dans squelettes utilisés dans le public, pour éviter les conflits, on propose `sp-icone`. Exemples : ``` <button class="sp-icone_menu">Ouvrir le menu</button> <h2 class="titrem sp-icone_machin">Mon titre</h2> ``` ### 2) Une balise #ICONE En complément, on peut vouloir embarquer une icône svg dans le HTML. On propose de reprendre et d'adapter la balise `#ICON` du plugin Zcore, qui fait ça très bien. Cette balise permet d'embarquer une icône du set par défaut, mais également n'importe quelle autre (je rentre pas dans les détails). Un modèle correspondant permettra aussi d'inclure des icônes svg dans les textes : `<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}`. Cela passerait par un pipeline, donc liste qui peut être complétée selon ses besoins. La liste initiale est visible ici : https://demo.hedgedoc.org/3zIXkcFLTVSwV0nKC1_qcA?both ## Ressources privé / public Cela veut dire 2 ressources à charger : * Une font-face pour les classes * Un sprite svg pour la balise Dans le privé, il faut charger les 2. Dans le public, cela pourrait se faire optionnellement, à la demande. ## Candidats Pour finir un tableau comparatif des jeux d'icônes possibles (à licences libres), avec mes commentaires initiaux. Petite préférence pour Feather actuellement. edit: voir aussi https://icones.js.org/ | Lib | Nb | sprite | fontface | Commentaire | |---|---|---|---|---| | [Bootstrap](https://icons.getbootstrap.com/) | 1300+ | 693ko | 85ko | Clés en main, beaucoup d’icônes (trop ?) | | [Feather](https://feathericons.com/) | 286 | (~100ko)| - | Styles rounded. Bonne balance nb icônes / poids. | | [Octico](https://github.com/primer/octicons/) (Github) | 433 | (~240ko) | - | Styles rounded. Bonne balance nb icônes / poids. Beaucoup de manips à faire pour créer sprite et cie. | | [Material](https://fonts.google.com/icons?selected=Material+Icons) (Google) | ? | (?ko)| 44ko | Style rounded / épaisseur variable. Beaucoup de manips à faire pour créer sprite et cie. Google ! | | [Core-ui](https://icons.coreui.io/icons/) | 554 | 418ko | 63ko | Clés en main. Sets inutiles non pris en compte dans ce tableau (brands, flags, …) | | [Bytesize](https://github.com/danklammer/bytesize-icons) | 101 | 11ko | - | Style rounded / épaisseur variable. Léger : le minimum syndical. | | [Open Iconic](https://useiconic.com/open) | 223 | 45ko | 15ko | | | [Forkawesome](https://forkaweso.me/Fork-Awesome/icons/) | 796 | (~660ko) | 109ko | | | [Remix](https://remixicon.com/) | 2271 | | | | | [Ikonate](https://ikonate.com/) | | | | Designées pour être accessibles | Sprite entre parenthèses = non fourni dans le dépôt ou la dist → poids théorique.

Les fontes d'icônes c'est pas top, c'est un peu déprécié aujourd'hui, ça pose pas mal de problèmes.
Mais si ça devait être utilisé, il faudrait des <span class="icone truc" aria-hidden="true"> plutôt que des <i class="spicon_truc"></i>

Et les gros fichiers de sprites svg, ça diminue le nombre de hits, c'est sûr, mais charger plusieurs centaines de Ko de Sprites pour afficher 3 icônes, c'est peut être beaucoup.
Et c'est la misère à mettre à jour sans outil spécialisé qui regénère tout le code, et vérifier que ça ne casse pas des choses...

moi j'ai du mal avec "spipcon". Ca fait "petit con", et c'est pas compréhensible si on a pas l'historique derrière. Pour gagner 5 caractères...

Les fontes d'icônes c'est pas top, c'est un peu déprécié aujourd'hui, ça pose pas mal de problèmes.

Pour la partie « icônes purement en CSS », c'est à dire sans rien de plus dans le HTML, je crois qu'on n'a pas trop le choix.
Dans ce cas ce sont des pseudos-éléments CSS :before ou :after, si on veut que l'icône hérite de la couleur et de la taille du texte, rien d'autre ne marche à ma connaissance. Pas les svg en background-image en tout cas.

D'ailleurs au passage mon 2ème exemple était mauvais : <i class="spicon_truc"></i> Du texte → dans ce cas c'est la balise #ICONE qu'il faut utiliser.
Pour les icônes CSS, la proposition était bien de n'avoir à qu'à ajouter une classe sur un élément existant, sans <span> ou <i> supplémentaire à l'intérieur.

Mais du coup oui, on tombe plein pot sur le problème soulevé par ces icônes à base de fontface : à priori les lecteurs d'écran vont lire ces caractères abscons, et sans moyen de les cacher puisque c'est purement du CSS.

Moi au départ je pensais que la balise #ICONE suffirait : des icônes présentes dans le HTML, ce qui permet de gérer tout les attributs d'accessibilité finement.

Et les gros fichiers de sprites svg, ça diminue le nombre de hits, c'est sûr, mais charger plusieurs centaines de Ko de Sprites pour afficher 3 icônes, c'est peut être beaucoup.

C'est bien pour ça qu'il faut trouver une balance entre le poids et le nombre d'icônes dispos.
La proposition à moyen et long terme c'est de généraliser l'usage de ces icônes dans le privé de Spip, donc ça sera pas chargé pour rien.

Et c'est la misère à mettre à jour sans outil spécialisé qui regénère tout le code, et vérifier que ça ne casse pas des choses...

C'est bien l'idée :)
Un outil à piori dans un dépôt à part qui genère tout seul le sprite et le reste.

moi j'ai du mal avec "spipcon". Ca fait "petit con", et c'est pas compréhensible si on a pas l'historique derrière. Pour gagner 5 caractères...

On se disait qu'on partirait plutôt sur sp-icone du coup.

> Les fontes d'icônes c'est pas top, c'est un peu déprécié aujourd'hui, ça pose pas mal de problèmes. Pour la partie « icônes purement en CSS », c'est à dire sans rien de plus dans le HTML, je crois qu'on n'a pas trop le choix. Dans ce cas ce sont des pseudos-éléments CSS `:before` ou `:after`, si on veut que l'icône hérite de la couleur et de la taille du texte, rien d'autre ne marche à ma connaissance. Pas les svg en background-image en tout cas. D'ailleurs au passage mon 2ème exemple était mauvais : `<i class="spicon_truc"></i> Du texte` → dans ce cas c'est la balise `#ICONE` qu'il faut utiliser. Pour les icônes CSS, la proposition était bien de n'avoir à qu'à ajouter une classe sur un élément existant, sans `<span>` ou `<i>` supplémentaire à l'intérieur. Mais du coup oui, on tombe plein pot sur le problème soulevé par ces icônes à base de fontface : à priori les lecteurs d'écran vont lire ces caractères abscons, et sans moyen de les cacher puisque c'est purement du CSS. Moi au départ je pensais que la balise #ICONE suffirait : des icônes présentes dans le HTML, ce qui permet de gérer tout les attributs d'accessibilité finement. > Et les gros fichiers de sprites svg, ça diminue le nombre de hits, c'est sûr, mais charger plusieurs centaines de Ko de Sprites pour afficher 3 icônes, c'est peut être beaucoup. C'est bien pour ça qu'il faut trouver une balance entre le poids et le nombre d'icônes dispos. La proposition à moyen et long terme c'est de généraliser l'usage de ces icônes dans le privé de Spip, donc ça sera pas chargé pour rien. > Et c'est la misère à mettre à jour sans outil spécialisé qui regénère tout le code, et vérifier que ça ne casse pas des choses... C'est bien l'idée :) Un outil à piori dans un dépôt à part qui genère tout seul le sprite et le reste. > moi j'ai du mal avec "spipcon". Ca fait "petit con", et c'est pas compréhensible si on a pas l'historique derrière. Pour gagner 5 caractères... On se disait qu'on partirait plutôt sur `sp-icone` du coup.

La fonte n'a aucune utilité à être insérée avec un HTML dédié avec une balise vide, que ce soit "i" ou "span" : si on a la main sur le HTML alors on doit plutôt l'insérer avec la balise, qui va utiliser le SVG, c'est la méthode à privilégier dans ce cas.

La fonte permet d'insérer une icône sur n'importe quel contenu déjà existant, justement parce qu'on n'a pas la main dessus, qu'on ne veut pas changer/surcharger son HTML. C'est à peu près la seule (mais grande) utilité d'avoir aussi la fonte.

Cela vaut notamment pour les noms sémantiques : si par exemple on a des boutons de suppressions (btn_supprimer) ou autre variante générique du même genre, et qu'on décide que cette variante doit avoir telle icône, alors ça doit être cohérent et ça doit avoir la même icône partout où il y a cette variante de bouton, core et tous les plugins du monde qui utilisent cette variante. Ensuite un an plus tard, on pense qu'un autre picto est mieux pour signifier la suppression : c'est juste un choix de déco, à aucun moment on ne doit avoir à modifier les dizaines d'utilisations dans le core + tous les plugins du monde, pour mettre un autre #ICONE, juste parce qu'on décide de changer le picto associé. On redéfinit ce que fait la classe CSS de la variante et c'est tout, c'est le principe même des CSS.

Sinon justement pour les pseudo-elements, il y a aussi une méthode officielle définie dans CSS pour ne pas forcément lire ces contenus !

À terme la méthode c'est ça :
https://www.w3.org/TR/css-content-3/#accessibility

content: 'un contenu affiché" / "un texte à lire";
content: 'un symbole imprononçable juste de déco" / "";

Donc il y a bien une méthode existante pour que les fontes soient parfaitement accessibles, sur n'importe quel élément déjà existant. Après faut que ça marche sur firefox etc, car certains ignorent encore la ligne sans la comprendre. Peut-être qu'il faut doublonner comme on faisait avec rgba() pour les navs qui connaissaient pas.
https://stackoverflow.com/questions/46815260/hide-a-pseudo-element-from-a-screenreader

Mais en tout cas ça existe et c'est déjà implémenté pour beaucoup de gens, et c'est de mieux en mieux, donc il n'y a pas trop trop d'inquiétude à se faire sur le long terme pour l'accessibilité des symboles ajoutées par pseudo-éléments.

La fonte n'a aucune utilité à être insérée avec un HTML dédié avec une balise vide, que ce soit "i" ou "span" : si on a la main sur le HTML alors on doit plutôt l'insérer avec la balise, qui va utiliser le SVG, c'est la méthode à privilégier dans ce cas. La fonte permet d'insérer une icône sur n'importe quel contenu déjà existant, justement parce qu'on n'a pas la main dessus, qu'on ne veut pas changer/surcharger son HTML. C'est à peu près la seule (mais grande) utilité d'avoir aussi la fonte. Cela vaut notamment pour les noms sémantiques : si par exemple on a des boutons de suppressions (btn_supprimer) ou autre variante générique du même genre, et qu'on décide que cette variante doit avoir telle icône, alors ça doit être cohérent et ça doit avoir la même icône partout où il y a cette variante de bouton, core et tous les plugins du monde qui utilisent cette variante. Ensuite un an plus tard, on pense qu'un autre picto est mieux pour signifier la suppression : c'est juste un choix de déco, à aucun moment on ne doit avoir à modifier les dizaines d'utilisations dans le core + tous les plugins du monde, pour mettre un autre #ICONE, juste parce qu'on décide de changer le picto associé. On redéfinit ce que fait la classe CSS de la variante et c'est tout, c'est le principe même des CSS. Sinon justement pour les pseudo-elements, il y a *aussi* une méthode officielle définie dans CSS pour ne pas forcément lire ces contenus ! À terme la méthode c'est ça : https://www.w3.org/TR/css-content-3/#accessibility ``` content: 'un contenu affiché" / "un texte à lire"; content: 'un symbole imprononçable juste de déco" / ""; ``` Donc il y a bien une méthode existante pour que les fontes soient parfaitement accessibles, sur n'importe quel élément déjà existant. Après faut que ça marche sur firefox etc, car certains ignorent encore la ligne sans la comprendre. Peut-être qu'il faut doublonner comme on faisait avec rgba() pour les navs qui connaissaient pas. https://stackoverflow.com/questions/46815260/hide-a-pseudo-element-from-a-screenreader Mais en tout cas ça existe et c'est déjà implémenté pour beaucoup de gens, et c'est de mieux en mieux, donc il n'y a pas trop trop d'inquiétude à se faire sur le long terme pour l'accessibilité des symboles ajoutées par pseudo-éléments.

Hello,

dans les jeux d'icone candidat il y a aussi ForkAwesome qui est un fork de la version 4.7 de FontAwesome, et est sous licence libre https://forkaweso.me/Fork-Awesome/icons/ et OpenIconic https://useiconic.com/open (mais je connais pas trop).

A noter plusieurs remarques :

il faut pas s'occuper du sprite fournit par défaut et de sa taille, car générer un sprite SVG à partir d'une liste d'icones est vraiment trivial, ça prend quelques lignes de PHP et on peut avoir un php-cli pour ça sans soucis. Je mets ci-dessous mon php de build des sprites SVG pour les icons bootstrap
du coup ça veut dire aussi qu'on peut avoir notre propre sprite avec les icones les plus courantes
et même amha assez simplement la balise #ICON pourrait détecter si l'image demandée est dans un sprite connu, auquel cas elle utilise le sprite, sinon elle utilise le fichier individuel

Par contre je suis pas fan du tout non plus des font face pour les icones, du coup j'ai pas intégré ça dans les plugins ZCore/BS/FontAwesome même si c'est vrai que parfois c'est bien embêtant de pas avoir les classes comme outil.
Le second inconvénient de la font-face aussi, c'est que pour le coup c'est beaucoup plus compliqué de maintenir ton sous-ensemble d'icones, tu es obligé de prendre toute la police fournie par la lib d'icone, et ça veut dire que tu charges tout dès que tu uilises juste une icone quelque part en CSS :(

Peut-être il faut regarder du côté

de SVGInjector https://github.com/iconic/SVGInjector qui propose une méthode pour injecter le SVG sur du HTML via JS ?
des CSS Masks, qui semblent supportés suffisament (hors IE) https://codepen.io/noahblon/post/coloring-svgs-in-css-background-images et permettrait de faire ça

.icon {
    background-color: currentColor;
    -webkit-mask-image: url(icon.svg);
    mask-image: url(icon.svg);
}

Pour finir sur la méthodo, je pense qu'il faut murir le sujet et l'implémentation dans un plugin, qu'on pourra utiliser et affiner et l'intégrer au core le cas échéant dans une prochaine release.

Mon script de build pour les sprites

#!/bin/php
", "", $svg);


  if (strpos($file, '-fill') !== false) {
    $sprite_fill .= "$svg\n";
  }
  else {
    $sprite .= "$svg\n";
  }
}

$sprite_all = "\n$sprite\n$sprite_fill";
$sprite = "\n$sprite";
$sprite_fill = "\n$sprite_fill";

file_put_contents($f = "bi-all-symbols.svg", $sprite_all);
file_put_contents($f = "bi-symbols.svg", $sprite);
file_put_contents($f = "bi-fill-symbols.svg", $sprite_fill);
passthru("ls -l bi-*.svg");

Hello, dans les jeux d'icone candidat il y a aussi ForkAwesome qui est un fork de la version 4.7 de FontAwesome, et est sous licence libre https://forkaweso.me/Fork-Awesome/icons/ et OpenIconic https://useiconic.com/open (mais je connais pas trop). A noter plusieurs remarques : - il faut pas s'occuper du sprite fournit par défaut et de sa taille, car générer un sprite SVG à partir d'une liste d'icones est vraiment trivial, ça prend quelques lignes de PHP et on peut avoir un php-cli pour ça sans soucis. Je mets ci-dessous mon php de build des sprites SVG pour les icons bootstrap - du coup ça veut dire aussi qu'on peut avoir notre propre sprite avec les icones les plus courantes - et même amha assez simplement la balise `#ICON` pourrait détecter si l'image demandée est dans un sprite connu, auquel cas elle utilise le sprite, sinon elle utilise le fichier individuel Par contre je suis pas fan du tout non plus des font face pour les icones, du coup j'ai pas intégré ça dans les plugins ZCore/BS/FontAwesome même si c'est vrai que parfois c'est bien embêtant de pas avoir les classes comme outil. Le second inconvénient de la font-face aussi, c'est que pour le coup c'est beaucoup plus compliqué de maintenir ton sous-ensemble d'icones, tu es obligé de prendre toute la police fournie par la lib d'icone, et ça veut dire que tu charges tout dès que tu uilises juste une icone quelque part en CSS :( Peut-être il faut regarder du côté * de SVGInjector https://github.com/iconic/SVGInjector qui propose une méthode pour injecter le SVG sur du HTML via JS ? * des CSS Masks, qui semblent supportés suffisament (hors IE) https://codepen.io/noahblon/post/coloring-svgs-in-css-background-images et permettrait de faire ça <pre> .icon { background-color: currentColor; -webkit-mask-image: url(icon.svg); mask-image: url(icon.svg); } </pre> Pour finir sur la méthodo, je pense qu'il faut murir le sujet et l'implémentation dans un plugin, qu'on pourra utiliser et affiner et l'intégrer au core le cas échéant dans une prochaine release. --- Mon script de build pour les sprites <pre> #!/bin/php <?php $files = glob('icons/*.svg'); $sprite = ""; $sprite_fill = ""; foreach ($files as $file) { $svg = file_get_contents($file); $svg = str_replace("width=\"1em\" height=\"1em\" ", "", $svg); $svg = str_replace(" fill=\"currentColor\" xmlns=\"http://www.w3.org/2000/svg\"", "", $svg); $svg = str_replace("class=\"bi bi-", "id=\"bi-", $svg); $svg = str_replace("<svg ", "<symbol ", $svg); $svg = str_replace("</svg>", "</symbol>", $svg); if (strpos($file, '-fill') !== false) { $sprite_fill .= "$svg\n"; } else { $sprite .= "$svg\n"; } } $sprite_all = "<svg xmlns=\"http://www.w3.org/2000/svg\">\n$sprite\n$sprite_fill</svg>"; $sprite = "<svg xmlns=\"http://www.w3.org/2000/svg\">\n$sprite</svg>"; $sprite_fill = "<svg xmlns=\"http://www.w3.org/2000/svg\">\n$sprite_fill</svg>"; file_put_contents($f = "bi-all-symbols.svg", $sprite_all); file_put_contents($f = "bi-symbols.svg", $sprite); file_put_contents($f = "bi-fill-symbols.svg", $sprite_fill); passthru("ls -l bi-*.svg"); </pre>

et même amha assez simplement la balise #ICON pourrait détecter si l'image demandée est dans un sprite connu, auquel cas elle utilise le sprite, sinon elle utilise le fichier individuel

Ça c'est bien prévu dans le cahier des charges :)

Pour les classes, si ya une autre méthode que la fonte tant mieux hein, mais ce qui compte c'est continuer d'avoir l'option des classes, surtout pour l'interface d'admin. Car il y a plein de cas où c'est utile quand on veut avoir une interface cohérente maintenable, surtout si elle est modulaire (plugins infinis qui doivent avoir aussi le même style, sans devoir tout changer partout dès qu'on veut changer le style d'un morceau, dont les pictos).

Et pour une interface d'admin, il y a encore moins de freinage y compris pour une fonte, on parle pas du site public qui utilise 3 pictos (là c'est au choix de la personne intégratrice de faire les bonnes décisions). Pour l'admin on charge de toute façon des choses permanentes, dont les sprites, et on va de toute façon utiliser un certain nombre de pictos un peu partout + en rendre dispo pour les plugins + le fait que les fontes sont à peu près toujours plus légères que les sprites. Avec tout ça je ne vois pas de problème énorme à charger une fonte de 80 pauvres kilos pour ce qui est de l'admin… (on parle pas de 500ko là…)
Batailler pour ne pas intégrer 80ko voire même 40ko si on prend un jeu moins gros que bootstrap, c'est un peu dérisoire… :)
(et du coup justement ya PAS à maintenir un sous-ensemble, car déjà l'ensemble complet pèse bien moins lourd que les sprites SVG, ça fait de la maintenance en moins)

Sauf que quand tu fais un truc pour l'admin en disant "c'est que pour l'admin", 4 matins plus tard un plugin le réutilise pour le public, les yeux fermés, sans regarder les conséquences, et tu te retrouves à gérer la merde ensuite (cf le dateur, cf jqueryui, ...)

Comme je disais, en SCSS j'ai une mixin qui me permet des trucs comme ça, ce qui transforme :

.machin {
	position: relative;
	&:after {
		content:'';
		position: absolute;
		right: -1em;
		top: 50%;
		transform: translateY(-50%);
		width: 7px;
		height: 7px;
		background: svg-url('') center no-repeat;
	}
}

mais bon, on va peut être pas mettre scssphp dans la dist...

On parle d'un woff de 80ko pour une lib de 1300 pictos, et donc sûrement carrément moins, 40ko, voire 30ko, voire 20ko, si on choisit une qui n'en a que 300. Même en choisissant celle à 1300 pictos, c'est sans commune mesure avec les 1Mo de UI (872ko de JS et 173ko de CSS). :)

There is no content yet.

Ça à l'air super intéressant le coup des CSS Masks en substitut des fontfaces.
Avec des classes utilisant le sprite svg (mask-image: url(sprite.svg#machin);, ça simplifierait beaucoup les choses : plus qu'une seule ressource à charger.
J'ai plus souvenir s'il y avait des difficultés avec les pseudos éléments + background-image pour les tailles, que ça prenne automatiquement celle du texte. Mais à tester donc.

Et du coup juste à partir des svg, on pourrait générer en même temps le sprite et la css, über pratique.
Ok pour tester tout ça dans un plugin à part dans un 1er temps.

Juste une remarque au niveau du choix du jeu d'icônes : je pencherais pour un qui rappelle un peu stylistiquement les icônes actuelles du bandeau, c'est à dire un peu "douces", en mode "rounded", sans trop d'angles droits.

Testé brièvement : les mask-image fonctionnent très bien en substitut de la font-face, et ça hérite bien de la taille du texte.
Donc partir des seuls svg il serait possible de générer à la fois le sprite et la CSS des classes sémantiques, super pratique.
Je crois que je vais partir là-dessus.

Un truc bizarre cependant : quand sur la même page on a à la fois un svg et une classe qui utilisent tous deux le même sprite svg, et bien le navigateur le charge 2 fois.
Peut-être qu'à ce compte là, la classe devrait utiliser les svg indépendants plutôt que le sprite. Enfin bon, ce seront des questions techniques secondaires à résoudre au fil de l'eau dans le plugin, je note juste ça au passage.

<svg width="1em" height="1em" fill="currentColor">
    <use xlink:href="sprite.svg#briefcase"/>
</svg>

<span class="sp-icone_briefcase">Texte avec icône CSS</span>
<style>
.sp-icone_briefcase:before {
  -webkit-mask-image: url("sprite.svg#briefcase");
  mask-image: url("sprite.svg#briefcase");
}
</style>

Je crois que les sprites SVG sont pas trop utilisables dans la css par contre, c'est pas supporté partout et c'est encore trop tot.

J'aurai tendance à dire que dans la css :

soit on utilise les url vers les simples svg : avantage le navigateur ne chargera que les pictos correspondant aux class utilisées et si on se sert pas de cette feature le cout est faible
soit on utilise des base64 : avantage tout est dans la css chargé en une fois, mais potentiellement bien inutile (auquel cas il ne faudra inclure cette css qu'en cas de besoin, dans le cas du public)

Mais du coup je crois en effet que quelle que soit la méthode on a des risques de double chargement (via le sprite pour la balise #ICON et via le fichier svg ou le base64 en css)

Ah mais du coup pointé dans la discussion sur les icones de l'espace privé https://remixicon.com/ semble un très bon package car

très complet : 1086 icones toutes déclinées dans une version line et une version fill + 99 sans déclinaison (les icones d'editeur genre h1, h2, sort, text-direction...)
totalement open source, sous licence Apache
catégorisées : on peut facilement faire un sprite par catégorie et par style (fill/line)
optimisées pour la lisibilité et pixel perfect
le sprite complet de 2271 icones fait 877ko ce qui donne un ratio de ~395 octets par icone ce qui en fait un pack bien efficace (derrière Bytesize et OpenIconic mais devant tous les autres, notamment les gros packs)
complètement indépendant

J'avoue que j'ai un faible pour ce jeu d'icones

Je penchais plus au départ pour des icônes en mode "rounded", mais faut avouer qu'elle est bien sympa cette remix.
Peut-être qu'en rusant il serait possible de forcer le style des terminaisons et des raccords pour arrondir légèrement. Mais bon ne bloquons pas là-dessus.
Si c'est celle-là qui est retenue, moi ça me va.

cedric - a écrit :

J'avoue que j'ai un faible pour ce jeu d'icones

+1, simples et élégantes, et sous licence libre.

+1 ne serait que pour la monochromie car à ce jour le privé de la 3.3 fait un peu sapin de noël :p

Oui, il semble très bien ce jeu d'icone.

L'auteur s'est mis en pause cela dit https://github.com/Remix-Design/RemixIcon/issues/232 a priori temporairement.
Mais effectivement y a pas eu de nouveaux commits depuis un petit temps. Espérons que la lib continuera sa vie.

Rien n'empêche de la forker si besoin :)

There is no content yet.

Version cible mise à 4.1

Des nouvelles ici du coup ?

Je vois que https://github.com/Remix-Design/RemixIcon/issues/232 est toujours ouvert d’ailleurs, et qu’il n’y a pas eu de fork proposant d’autres icones depuis… Pas d’autres nouvelles de l’auteur dans le ticket (un des commentaires évoque une version Pro)

Ben j'ai l'impression que RemixIcon est préféré. En outre, c'est aussi une source d'inspiration de la refonte des logos.
Je ne suis pas sur que le fait qu'il n'évolue plus depuis 18 mois soit un problème non ?

Par contre, j'ai jeté un oeil sur les autres et aucun ne me plait autant.

Mon avis pour l'instant : Remixicon a déjà ~1200 icônes, d'ici à ce qu'on ait besoin d'une nouvelle icône qui manquerait, le projet aura peut-être été repris, et au pire on pourra en ajouter nous-mêmes en suivant la même charte. Ça coche plein de critères, très complet de base, en variantes lignes et pleines, sobre, super lisible, catégorisées, déjà en svg et font…

Pardon, je me suis mal exprimé en fait. J’ai rien contre RemixIcon : je signale juste.

Ma question était surtout, est-ce que ça a avancé le ticket ? (je crois pas avoir vu mais je demande) (en rapport avec le commentaire sur #4750)

Idéalement on pourrait faire en sorte de ne pas s'enchaîner à un jeu d'icônes si on voit plus tard qu'il n'est pas maintenu ou autre.
C'est à dire avoir une base d'identifiants fixes pour les icônes les plus utiles, qui ne changerait pas en passant d'un set à l'autre (reste à voir comment, c'est juste une idée).

En attendant Remix à l'air de convenir.

Des nouvelles ici du coup ?

De mon côté j'avais commencé à implémenter quelque chose, puis j'avais buté sur des choix de conception. Depuis ça n'a pas trop avancé...
Il faut que je me replonge dedans et je détaillerai ici ce qui me bloque.

C'est à dire avoir une base d'identifiants fixes pour les icônes les plus utiles, qui ne changerait pas en passant d'un set à l'autre (reste à voir comment, c'est juste une idée).

La réponse est dans le plan de départ 😄 : il doit de toute façon y avoir un mécanisme de mapping entre des identifiants ajoutés en plus (sémantiques à priori ou pas, on met ce qu'on veut) et les vrais noms finaux d'icones (deplier => chevron-double-down).

Au passage un site qui recense pleins de sets d'icônes signalé par @rastapopoulos : https://icones.js.org/

Et un autre pack d'icône ici https://iconoir.com/

Iconoir is one of the biggest open source libraries with currently 1007 SVG Icons. No premium icons, no email sign-up, no newsletters.

Encore un autre pack de 1000 icones sous licence CCBY par ici https://app.streamlinehq.com/icons/streamline-mini-line

Un autre pour la route, issu de Carbon Design System par IBM https://carbondesignsystem.com/guidelines/icons/library/

Des nouvelles de ce côté ?

Pour info, feather qui semblait être à l'abandon a été forké vers https://lucide.dev/

J'ajoute une pièce dans la machine avec https://www.mingcute.com/

Et un autre pour la routé repéré par @marcimat :

< marcimat‎ > https://tabler-icons.io/ <- c’est ce qu’ils utilisent chez symfony je vois