#fonts

Perso je ne l’utilise plus beaucoup, je passe généralement par des outils plus simples qui se content de me convertir la police en WOFF et WOFF2 (les autres formats ne sont plus trop utiles désormais).

Par exemple :
►https://everythingfonts.com/otf-to-woff
►https://everythingfonts.com/otf-to-woff2

ou carrément en ligne de commande sous node.js :
►https://github.com/fontello/ttf2woff

Un petit tour par caniuse indique que Woff est compris par 97% des visiteurs en France (et Woff2 par 87%). Et par ailleurs, @font-face est aussi compris par 97% des visiteurs. Ce qui signifie que tous les visiteurs qui peuvent utiliser des webfonts avec @font-face peuvent en même temps utiliser Woff ; ce qui rend les autres formats (.eot, .svg, .ttf) inutiles.

Mais suivant la langue des contenus du site final, ça permet aussi de réduire le champs, et donc le fichier, ce que ne font pas forcément les autres outils qui ne font que conversion. Non ?

@rastapopoulos : oui effectivement. Mais l’utiliser parce que ça fait les multiples formats de fontes et le code dont on avait besoin il y a quelques années, je signale que ce n’est plus nécessaire.

#typographie

#fonts #graphisme #fontes #polices_de_caractère

L’article signale cette ressource intéressante pour les personnes qui utilisent ce genre de typos : ▻https://www.filamentgroup.com/lab/bulletproof_icon_fonts.html

Résumé :

– Quand on utilise la zone Unicode réservée aux trucs privés, si la fonte se charge mal, on a soit des rectangles pourris, soit des icônes n’ayant rien à voir (emojis, etc). Et si les utilisateurs (dyslexiques par ex) forcent une fonte propre à leur besoin, pareil, ça nique tout.

– Quand on fait bien les choses et qu’on utilise le bon caractère Unicode correspondant au dessin que l’on veut utiliser : beaucoup de lecteurs d’écran lisent la description du dessin ! Et le seul moyen de l’enlever est d’ajouter du « aria » dans le HTML en plus. Cela peut marcher dans certains cas, mais du coup impossible d’ajouter des icônes uniquement en CSS, dans le thème graphique.

Filament a produit une librairie utilitaire contenant CSS et JS nécessaire pour utiliser des fontes d’icônes de manière accessible :
▻https://github.com/filamentgroup/a-font-garde

Mais dans la solution de Filament, dans TOUS les cas d’utilisations, ils demandent à utiliser du HTML supplémentaire spécifique à l’icône. Donc d’après moi, c’est un peu pourri : impossible de faire le choix des icônes (ou pas) uniquement dans le thème graphique…

Sur le long terme, j’ai l’impression que la solution serait que tous les lecteurs d’écran prennent correctement en compte la propriété speak:none.
De cette manière, il suffirait :
1) d’utiliser un bon caractère unicode correspondant au mieux au dessin de chaque caractère de notre fonte d’icône (Fontello permet ça par ex), comme ça le fallback visuel serait bon (sauf s’il n’existe pas et dans ce cas faut utiliser la méthode fallback par image de Filament… galère)
2) d’appliquer sur tous les :before où on veut ajouter une icône, la directive speak:none

Mais actuellement même Caniuse.com ne contient pas les statistiques des propriétés orales de CSS… Il y a un ticket pour voter pour ça ici :
▻https://github.com/Fyrd/caniuse/issues/1515

Voilà, comment est-ce que vous allez faire à l’avenir vous ?

En ce qui me concerne, cela fait de nombreux mois que désormais mon HTML ne contient plus de scories pourries en rapport avec l’aspect graphique, que je n’utilise plus de classes genre « icon », « grid », ou je sais pas quelle merde comme ça, et que j’ajoute tout en CSS grâce aux préprocesseurs (exemple : a.super_lien{ @extend .icon; @extend .icon-super; }).
Du coup la solution de Filament m’embête vraiment…

#accessibilité #icônes #fontes #fonts #intégration #HTML #CSS

Et tiens cc @notabene @nhoizey pour intégration/accessibilité.

Pour ma part, les pictos sont en SVG inline, tout simplement. Si je devais me préoccuper de fallback (je parle de mes projets perso uniquement), j’utiliserais <picture> avec une source SVG et le fallback en PNG.

Merci @rastapopoulos pour le ping, je pensais l’avoir dans mes propres liens, mais ce n’est pas encore le cas…

Nan mais si c’est un truc avec des couleurs, etc, ben oui c’est une image, on l’utilise comme une image. Les icônes en fonte pour moi c’est clairement pour les pictogrammes : qui justement doivent suivre UNE couleur choisie en CSS (celle du texte courant très souvent, et parfois une autre), et à utiliser pour différencier des liens, des boutons, etc, tout en restant sobre.

[ Éditer ] [ Supprimer ]
versus
[ ✎ Éditer ] [ ✖ Supprimer ]

Et dans ces cas là, le fait d’en vouloir ou pas, et le fait de vouloir tels ou tels pictos : c’est un choix du thème graphique. Donc pour moi c’est entièrement au thème graphique de les activer ou pas, et de choisir quelles images ou pas. Sans RIEN changer au HTML (qui ne contient que des classes permettant de différencier le sens de divers liens par exemple, pas leur aspect : « supprimer », « favoris », « inscription », etc).

Le fait de devoir mettre des <img> (ou même des <span> vides) dans le HTML pour afficher des icônes et non des vraies images, c’est totalement carrément plus du hack (comme il dit dans le lien de départ), qu’utiliser des fontes en CSS. Le fait d’avoir ces pictos, c’est une aide visuelle pour aider à mieux distinguer certains éléments pour celleux qui ont des yeux, mais le lien ou bouton lui c’est juste « Éditer » (par ex).

Ah et faut ajouter (et ça a été écrit dans les commentaires) que les fontes informatiques, avec unicode, ont été faites pour contenir des lettres ET des pictos. Donc ce n’est absolument pas un hack du tout, c’est parfaitement prévu, et donc c’est aux navigateurs (visuels ET auditifs) et aux normes web (CSS), de savoir les gérer comme il faut.

Après pour les interfaces où on a des liens ou boutons qui n’ont QUE l’image/picto, là c’est encore autre chose. Mais pour le coup ça pose encore plus de problème ergonomique avant même l’accessibilité : une image seule, tant qu’on ne connait pas l’appli ou le site, difficile de savoir à quoi ça mène (et maintenant dans tous les trucs tactiles on a pas de bulle de survol puisque pas de survol, mais même pour celleux qui ont une souris, ce n’est pas normal de devoir déplacer sa souris un peu partout sur l’écran pour savoir ce que fait l’interface !), donc sauf cas rare et très précis, c’est pour moi de toute façon une mauvaise pratique.

Pourquoi les pictos devraient-ils n’avoir qu’une seule couleur ?

(oui, je sais, les fontes multicolores arrivent…)

Pour ce point, Fontello fait déjà tout ça pour toi, comme IcoMoon mais en logiciel libre et gratuit. Tu peux importer tes SVG perso, puis les sélectionner comme caractères, et leur assigner un code unicode. Ensuite ça te génère la fonte dans plein de formats, et le CSS qui va avec (comme IcoMoon encore une fois).

Une réponse là ▻http://seenthis.net/messages/435520
Mais qui ne prend pas en compte vraiment les problèmes d’accessibilité (juste utiliser le PUA ne suffit pas, puisqu’il y a le problème des fallbacks, et des polices forcées autrement). Or ce sont ces problèmes dont parlent en priorité l’article de départ.

L’explication plus technique de comment ils fonctionnent chez Cloudfour :
▻http://seenthis.net/messages/457318

#font #webperf #développement #web #intégration #CSS

Bon j’ai envoyé un mail à l’auteur car impossible de commenter sur son Disqus sans avoir un compte autre part, et il m’a répondu, à propos de test de connectivité, donc je vous en fait profiter :

I think connectivity tests just aren’t reliable now. You can maybe make some predictions, but there are many factors, which make it almost impossible to guess appropriate enough. On a mobile device it also changes almost every time e.g. when you are travelling.

The cool thing about my method is that the browser loads those fonts asynchronously and it doesn’t really matter whether the font files can be downloaded or not, because the content is always going to be visible. In the worst case it will be displayed with fallback fonts.

What could be more interesting is to optimize the font stack. Each device has some default fonts which are always installed: like Roboto on Android, Tahoma on Windows etc.

Et effectivement, un truc intéressant, dans la pile de polices, après avoir mis celle qui doit être téléchargée, mais avant celles qui sont génériques ("verdana", « sans », etc), c’est d’arriver à trouver des polices qui sont dans chacun des systèmes un peu connu du marché (Windows 7 et 8, Android, OSX, Ubuntu, etc).

De cette manière, même sans avoir encore chargé la police voulue, le site sera tout de même plus joli qu’avec du verdana !

C’est, entre autre, aussi une idée pour la dist de #SPIP même quand on ne charge aucune police !

La suite, toujours du même auteur :

In my previous article about webfont loading I showed a technique about how to load webfonts without blocking page rendering and without annoying the users with flickering text on all pageloads. This time I show you an optimized version of the script and provide a solution for WOFF2 support for the newest browsers.

Expectations

– The users must see the text as soon as possible.
– As longs as the font is loading, the text must be rendered with the fallback font so that users can see and read it.
– Users shouldn’t be annoyed with flickering text on each page load.
– Modern browsers with WOFF2 support should receive the fonts in WOFF2 format. This means ca. 30% less filesize.

▻http://bdadam.com/blog/better-webfont-loading-with-localstorage-and-woff2.html

Ça serait pas mal d’arriver à automatiser ça dans SPIP. #idée_pour_SPIP

Sans compter que certaines langues comptent d’insoupçonnables difficultés pour leur dessiner une police, le tamul par exemple est cette merveilleuse langue aux 256 caractères, sur sept hauteurs différentes et de très très belles courbes. Je pense qu’il faut à peu près douze fois le travail pour une seule police qu’il nen faudrait pour une police romane.

▻http://fr.wikipedia.org/wiki/Égyptienne_(typographie)

et ▻http://fr.wikipedia.org/wiki/Classification_Vox-Atypi#Les_m.C3.A9canes

Pour ce qui est des textes de très petite taille, peut être. Mais l’ériger en valeur absolue serait une erreur : ça voudrait dire que le Garamond (petite hauteur d’x) est illisible ce qui est absurde. À espace égal une plus grande hauteur d’œil est probablement préférable, mais lorsqu’on peut composer finement, cette considération devient secondaire.

C’est ce que je voulais dire par « À espace égal une plus grande hauteur d’œil est probablement préférable, mais lorsqu’on peut composer finement, cette considération devient secondaire. » Mais ça ne corrobore pas « D’autre part, il semble qu’une sorte de fatalité soit à l’œuvre, qui obligerait à choisir entre “belle” police et police lisible ».

À mon avis, se focaliser sur « la plus lisible » dans une combinaison donnée est forcément frustrant de ce point de vue : y’en a forcément qu’une qui est « la plus lisible », par définition. « Bien lisible » me semble un critère plus opératoire, et à ce titre, le Jenson doit souvent fonctionner : )

Deutsche #Kurrent - & #Fraktur - #Schriftarten

[ #Sütterlin ]

►https://fr.wikipedia.org/wiki/Kurrent

La Deutsche #Kurrentschrift ou Kurrent, « écriture cursive allemande », est une #écriture utilisée en Allemagne et dans les pays de culture germanique jusqu’au milieu du XXe siècle. L’étymologie est le latin currere, « courir », qui a également donné le français « cursive ». C’est la forme manuscrite des diverses formes de gothique allemande ou Fraktur utilisées par l’imprimerie. Bien qu’on l’oppose à l’écriture latine, c’est aussi une forme d’écriture latine, avec ses spécificités propres. [...]

#retro #privacy