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

Open
opened 4 months ago by tcharlss · 21 comments
Owner

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.

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

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

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

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

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

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é

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

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

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

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

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

Comme je disais, en SCSS j'ai une mixin qui me permet des trucs comme ça, ce qui transforme : <pre> .machin { position: relative; &:after { content:''; position: absolute; right: -1em; top: 50%; transform: translateY(-50%); width: 7px; height: 7px; background: svg-url('<svg width="7" height="7"><circle cx="3.5" cy="3.5" r="3" fill="#000"/></svg>') center no-repeat; } } </pre> 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). :)

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). :)
Poster
Owner
There is no content yet.
Poster
Owner

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

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

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

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)

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

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

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

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.

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

cedric - a écrit :

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

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

cedric - a écrit : > J'avoue que j'ai un faible pour ce jeu d'icones +1, simples et élégantes, et sous licence libre.
Owner

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

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

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.

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

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

Rien n'empêche de la forker si besoin :)
Poster
Owner
There is no content yet.
Owner

Version cible mise à 4.1

**Version cible mise à 4.1**
Sign in to join this conversation.
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.