Revisions : SPIP

http://core.spip.org/projects/spip/activity

Les articles publiés sur le site

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

    13 avril 2021, par cedric -

    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é

    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
<?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);

  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");

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

    12 avril 2021, par RastaPopoulos ♥

    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.

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

    12 avril 2021

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

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

    12 avril 2021, par Maïeul Rouquette

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

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

    12 avril 2021, par nicod _

    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 plutôt que des

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

Navigation

Sites Web