Typographisme - Design Web

De la césure et du Web

Jeremie — Tue, 06 Mar 2012 09:00:00 +0100

La césure (ou « hyphen » en anglais) est une coupure de mot qui survient en fin de ligne. Il s’agit d’un artifice bien connu des composeurs pour gérer les lignes de texte justifié depuis des siècles. Jusqu’à présent, son usage sur le Web était difficile, on la disait même parfois impossible. Cependant, comme vous allez le voir, beaucoup de choses sont en fait possibles. Entre solutions des temps anciens et nouveautés de CSS3, voyons comment démocratiser l’usage des césures sur le Web.

Photo : Stéphane Champagne

Au début était HTML

Contrairement à une idée reçue, la césure est un mécanisme relativement ancien sur le Web. En effet, des possibilités de césure existaient déjà dans les vieilles versions d’Internet Explorer (avant même sa version 6) et font partie de la norme HTML depuis au moins sa version 3.2.

Historiquement donc, HTML définit deux méthodes permettant de spécifier des opportunités de césure [1] :

L’entité de caractère 
Cette entité HTML représente le caractère « césure douce » [2]. Ce caractère est invisible jusqu’à ce qu’une césure soit réellement pratiquée, auquel cas, il apparaît comme un tiret.
La balise <wbr>
Cette balise fait quasiment la même chose que l’entité . La seul différence tient au fait que cette balise ne matérialisera pas les césures sous forme d’un tiret. À l’origine c’est une balise non standard largement implémentée dans les navigateurs (à commencer par Internet Explorer) qui, au vu de son large support, a finalement été standardisée dans HTML5.

Un des usages les plus courants de ces deux éléments consiste à définir soi-même les opportunités de césure sur des mots particuliers :

<p>Des opportunités de césures pour le mot « anti&shy;con&shy;sti&shy;tu&shy;tion&shy;nel&shy;lement »</p>

La balise <wbr> est plus appropriée pour les cas où un tiret de césure induirait une ambiguïté comme dans les URL :

<p>http://<wbr>typographisme.net/<wbr>post/<wbr>De-la-cesure-et-du-Web</p>

J’ai réalisé une petite page de test où vous pouvez voir toutes ces techniques en action.

Le principal problème de cette méthode, c’est qu’elle requiert que vous définissiez vous-même, à la main, toute les opportunités de césure. Autant ce peut être acceptable pour un mot de-ci de-là, autant cela relève de l’utopie lorsqu’il s’agit de gérer un texte complet. Ceci dit, rien ne vous empêche de gérer ces opportunités de césure via un script côté serveur, qui fera le travail pour vous.

Du point de vue de l’accessibilité par contre il faut vous méfier, ces deux mécanismes étant gérés de manière assez disparate par les assistances techniques. Selon les outils utilisés le rendu peut alors être assez différent. A titre d’exemple, VoiceOver avec Safari a tendance à vocaliser les mots sous forme de syllabes. Si vous avez des retours d’expérience concret sur ce point, les commentaires vous tendent les bras.

Puis vint JavaScript

Pour automatiser tout ça, une autre option consiste à utiliser JavaScript. Pour cela, il existe plusieurs solutions, de la plus frustre (à base d’expressions régulières) à la plus élégante (via hyphenator.js).

À titre d’exemple, l’utilisation du script hyphenator (qui, soulignons-le, fait les choses dans les règles de l’art) est redoutablement simple :

<p class="hyphenate">D'abord un gardien de Camargue...</p>

<script src="http://typographisme.net/post/Hyphenator/Hyphenator.js"></script>

<script>
Hyphenator.run();
</script>

Toujours sur la page de test, vous pouvez voir ce script en action.

Au-delà de cette simplicité de façade, ce script offre de nombreuses possibilités de personnalisation que je ne vous détaillerai pas ici mais qui vous permettront de raffiner vos césures en fonction de vos besoins.

Ceci dit, l’utilisation de ce genre de script peut avoir un coût particulièrement significatif pour les performances de votre site. En effet, au-delà des calculs que doit faire le navigateur pour positionner les entités  là où il le faut, une bonne gestion des césures nécessite ce que l’on appelle un « dictionnaire de césure ». En effet, une césure, ça ne se place pas n’importe où et chaque langue a ses propres règles en la matière. Ainsi, pour éviter les césures disgracieuses, il faut définir toutes les règles d’application.

Ces règles peuvent, selon les langues, être assez volumineuses et alourdir considérablement le poids de votre page. À titre d’exemple, le dictionnaire de césure d’hyphenator pour le hongrois fait 455Ko (!), pour l’allemand 79Ko et pour l’anglais britannique encore 45ko… mais pour le français, seulement 8ko et moins de 2ko pour l’italien. Soyez donc prudent si vous utilisez cette solution, en particulier dans un environnement à faible bande passante comme les réseaux mobiles.

Enfin apparut CSS

Ainsi, jusqu’à présent, les solutions dont nous disposions n’étaient pas forcément très aisées à mettre en oeuvre pour gérer les césures. Néanmoins, les choses changent. Ainsi le module CSS3 Text définit une nouvelle propriété nommée hyphens. Elle va nous permettre de gérer la césure automatique des mots à l’aide d’une simple déclaration CSS : bonheur et simplicité.

<style>
.hyphenate {
    hyphens: auto;
}
</style>

<p class="hyphenate">D'abord un gardien de Camargue...</p>

Cette propriété étant encore jeune, elle n’est pas encore bien répandue. Cependant, au moment où j’écris ces lignes, elle commence à être disponible en version préfixée :

Firefox (avec le préfixe -moz-) a été le premier à la mettre en œuvre pour une trentaine de langues environ à l’heure actuelle,
Chrome et Safari (avec le préfixe -webkit-) sont également dans la course, mais les langues supportées en dehors de l’anglais ne sont pas connues.
Enfin, Internet Explorer 10 (avec le préfixe -ms-) va s’y mettre à son tour avec une vingtaine de langues à son actif.

Là aussi, la page de test vous permet de voir le résultat de cette propriété CSS.

Le principal intérêt de cette méthode est que les dictionnaires de césure dont nous parlions précédemment sont directement embarqués au sein du navigateur et n’alourdissent donc pas votre page. Ceci dit, comme nous l’avons vu, ces dictionnaires peuvent être volumineux et certains éditeurs de navigateur font le choix de ne pas les fournir sur les versions mobile de leur navigateur, afin que celles-ci restent le plus compactes possible sur des plateformes à faibles capacités. Il n’y a donc pas de garantie de fonctionnement systématique de cette solution qui, rappelons-le, reste expérimentale.

Le mot de la fin

Avec ce tour d’horizon, vous n’avez désormais plus d’excuse, vous pouvez utiliser les césures sur le Web. En fonction de vos prérequis, vous êtes libre de choisir la technique qui vous convient le mieux : toutes ont leurs avantages et leurs inconvénients. À vous de peser le pour et le contre mais maintenant, vous le savez, c’est possible.

Ceci étant dit, ce n’est pas parce que c’est possible qu’il faut le faire. À titre très personnel, je fais partie de ces gens qui ont toujours trouvé que les césures sont horriblement disgracieuses. En ces temps modernes de l’informatique, il existe d’autres solutions plus élégantes pour répartir les blancs au sein des lignes sans avoir à couper les mots. Les utilisateurs de technologies comme LaTex le savent bien, il existe des algorithmes mathématiques capables de créer des textes justifiés sans césure ni rivière de blanc en son sein. Peut-être un jour verrons-nous cela dans nos navigateurs mais, pour des raisons extrêmement techniques, ce n’est malheureusement pas pour tout de suite. En attendant, et bien… s’il le faut vraiment, coupez les mots.

Une opportunité de césure, c’est un endroit où le navigateur aura le droit de réaliser une césure. Par contre, le fait qu’il y ait ou non une césure à cet endroit spécifique dépend de ses propre règles internes. [retour]
« Soft hyphen » dans la langue de Shakespeare, nom de code U+00AD en Unicode [retour]

Macro-typographie sur le Web – Une grille dynamique

Vincent — Fri, 29 Apr 2011 08:37:00 +0200

« Une grille typographique est une structure à deux dimensions faite de séries d’axes verticaux et horizontaux s’intersectant utilisés pour structurer le contenu. »

Passé cette définition trouvée sur Wikipedia un peu abrupte, je retiendrai pour ma part l’explication qu’en faisait Anne-Sophie lors du dernier cycle de conférence Paris-Web : notre cerveau a besoin pour pouvoir anticiper au mieux de ne pas être distrait dans sa tâche principale. Lui proposer une structure logique et répétitive permettra donc de faciliter la lecture.

L’analogie avec les marches d’escalier m’a d’ailleurs terriblement convaincu… C’est quand même plus agréable de ne pas devoir regarder ses pieds à chaque marche !

Photographie sous licence Creative Commons par Pierre Bédat.

Après avoir passé en revue outils et techniques pour travailler correctement avec des grilles de mise en page verticales et horizontales, il est temps de s’affranchir des défauts inhérents à la bibliothèque précédemment choisie (Blueprint) ; mais aussi y apporter une plus grande… Soup–Less–e !

Voyons ensemble les avantages à compiler les feuilles de style ! (Et c’est promis, plus de jeu de mots.)

Rappels

Nous avions identifié trois défauts importants à l’utilisation d’un framework CSS :

des classes non-sémantiques présentes dans le code HTML ;
une portabilité de la structure qui s’en retrouve compliquée ;
un poids de fichiers assez important.

Essayons de nous en affranchir au mieux à l’aide de Less.

Less

Less est un compilateur CSS (tout comme son « concurrent » Compass) qui permet d’ajouter des notions de programmation à vos feuilles de style.

Sa syntaxe se veut facile à appréhender puisque basée sur une syntaxe CSS enrichie. On déclare ainsi @variables, .fonctions(){…}, et #autres{#imbrications{…}}.

C’est très simple et très rapide à comprendre mais surtout, cela permet plein de nouvelles choses… Qu’on ne soupçonne peut-être pas au premier abord !

Méthodologie

Installer Less est assez simple. Vos CSS actuelles renommées avec une nouvelle extension Less seront immédiatement compatibles. Il ne reste plus qu’à mettre en place le compilateur. Pour cela plusieurs cas de figure en fonction de votre environnement :

Les Linuxiens adeptes de la ligne de commande préféreront sans doute passer par une version serveur du compilateur.
Les Maqueux adeptes de la simplicité auront la chance de pouvoir compiler en toute transparence leurs fichiers à l’aide d’un petit logiciel résident.
Les Windowsiens adeptes des mauvaises idées devront se contenter d’un compilateur en JavaScript.

Oubliez les trolls (merci d’avance), je ne souhaite que pointer du doigt la mauvaise idée qui consiste bien évidemment à laisser en production le compilateur JS. Dans ce cas, la présentation de vos pages dépendrait uniquement du support JavaScript de votre client…

N’oubliez donc pas si vous utilisez le compilateur côté client de le débrancher en fin de développement. Et de lier de manière tout à fait conventionnelle votre toute nouvelle CSS compilée par ses soins.

Il existe d’ailleurs sous Windows quelques solutions à creuser qui permettront de contourner l’obstacle.

Une grille configurable

Maintenant que notre nouvel outil est en place, il est possible d’imaginer de nouvelles choses.

Pour rappel Blueprint propose par défaut une grille verticale de 24 colonnes de 30 pixels de large séparées entre elles par des gouttières de 10 pixels.

En modifiant la bibliothèque et définissant quelques variables, on peut alors facilement composer n’importe quelle autre grille. Il suffit pour cela de configurer la largeur de colonnes, leur nombre, et la largeur de leurs gouttières.

La bibliothèque tout entière sera alors générée en fonction de ces paramètres et même #grid (l’outil bien pratique utilisé en surimpression de la page) s’adaptera aux nouvelles exigences.

Envie d’essayer 960 Grid System par exemple ? Hop :

 @column: 60px; // des colonnes confortables  ;
 @margin: 20px; // des gouttières plus larges ;
@columns: 12;   // et un nombre de colonnes divisible par 2, 3, 4 et 6.

C’est très simple et tout peut-être ainsi configuré à notre convenance : grilles, marges, bordures, couleurs, etc.

Une séparation stricte du contenu et de la présentation

On reproche aussi souvent aux bibliothèques CSS d’introduire un code non-sémantique dans les fichiers HTML. Ce qui pose bien évidemment quelques soucis lorsqu’il s’agit d’adapter la grille à différents périphériques, nous l’avons vu précédemment.

Pour illustrer mon propos, partons de ce bout code très classique (un contenu principal composé d’un titre, d’un paragraphe d’introduction et de contenu standard ; une colonne secondaire) :

<div class="clearfix" lang="la">
   <div class="span-6">
      <p>Lorem ipsum dolor…</p>
   </div>
   <div class="span-18 last">
      <h1>Sit amet !</h1>
      <p class="large">Magna aliquam erat volutpat…</p>
      <p>Consectetur adipiscing elit…</p>
   </div>
</div>

Avec Less, notre code HTML va se simplifier et devenir bien plus sémantique (plus aucune classe ne traîne, si ce n’est le first-child, présent ici pour des raisons de compatibilité avec le plus ancien des navigateurs du moment) :

<div id="page" lang="la">
   <div id="sidebar">
      <p>Lorem ipsum dolor…</p>
   </div>
   <div id="content">
      <h1>Sit amet !</h1>
      <p class="first-child">Magna aliquam erat volutpat…</p>
      <p>Consectetur adipiscing elit…</p>
   </div>
</div>

Notre feuille de style au format Less récupère alors simplement les informations de présentation :

#page
{
   .clearfix;

   #sidebar
   {
      .span(6);
   }
   #content
   {
      .span(18);
      .last;

      p.first-child
      {
         .large;
      }
   }
}

On pourra alors adapter facilement sa présentation en fonction de la taille d’écran du terminal client, notamment à l’aide des media-queries.

Il suffira par exemple de ne plus positionner la colonne et le contenu l’un à côté de l’autre, mais l’un au dessus de l’autre, séparés visuellement par une bordure. Plus besoin ici de s’embêter avec first-child : IE 6 ne supportant pas de toute manière les media-queries.

@media (max-device-width: 480px)
   #page
   {
      #sidebar
      {
         border-bottom: 1px solid #000;
         margin-top: -1px;
         .append-bottom();
      }
      #content
      {         
         p:first-child
         {
            .large;
         }
      }
   }

Comment ça marche ?

Deux techniques sont employées ici :

l’héritage, qui nous permet de ne pas réécrire inutilement des portions de code ;
les fonctions, qui nous permettent de produire un code CSS différent en fonction de variables.

Dans Blueprint nous avons :

.large
{
   font-size: 1.2em;
   line-height: 2.5em;
   margin-bottom: 1,25em;
}

Il n’est pas besoin de copier/coller les propriétés du sélecteur : il suffit d’en hériter.

De la même manière pour les colonnages, au lieu de passer par :

.span-6
{
   width: 230px;
}
.span-6
{
   float: left;
   margin-right: 10px;
}

Il suffira de coder une petite fonction pour en automatiser la tâche :

.span(@level)
{
   float: left;
   margin-right: @margin;
   width: (@level * @column) + ((@level - 1) * @margin);
}

Ce qui revient à calculer automatiquement :

.span(6)
{
   float: left;
   margin-right: 10px;
   width: (6 * 30px) + (5 * 10px); // soit 230 pixels
}

Il sera même possible de « casser » la grille par moments en passant en paramètre un nombre à virgule et créer ainsi des demi-colonnes par exemple…

Simplifier les calculs en `em`

Puisqu’il est possible d’effectuer des calculs simples, cela va grandement simplifier tout ce que nous devions réaliser sur la base de règles de trois. En particulier les calculs sur les tailles de textes.

Voici une petite fonction d’exemple :

.font-size(@after)
{
   @before     : 12;    // la taille de texte par défaut (en pixels après calculs)
   @line-height: 1.5em; // la hauteur de ligne par défaut
   @ratio      : 3 / 2; // le ratio entre la hauteur de ligne et la taille de texte

       font-size: @line-height / @ratio * @after / @before;              // la nouvelle taille  de texte calculée (exprimée en em)
     line-height: @line-height * (@before * @ratio) / (@after * @ratio); // la nouvelle hauteur de ligne calculée (exprimée en em)
   margin-bottom: @line-height * (@before * @ratio) / (@after * @ratio); // la marge ajoutée en bas de l’élément égale à la nouvelle hauteur de ligne
}

Elle facilitera grandement la mise en place d’un corps de texte sur un paragraphe :

p.de-bonne-taille
{
   .font-size(15); // on demande 15 pixels mais les résultats seront bien exprimés en em
}

Le code CSS une fois compilé aura cette allure :

p.de-bonne-taille
{
   font-size: 1.25em;    // soit 15 pixels
   line-height: 1.2em;   // soit 18 pixels
   margin-bottom: 1.2em; // soit 18 pixels
}

Des fichiers optimisés

Dernier avantage à cette technique : le poids de vos fichiers CSS s’en trouve optimisé. Plus besoin de prévoir tous les cas de figure pour vos colonnages, vous n’embarquez dans vos fichiers compilés que ce qui vous est nécessaire. Exit donc ce défaut également.

Sans compter que – cerise sur le gâteau – le code CSS une fois compilé peut-être automatiquement compressé.

Blueprint passe ainsi de 13,2 Ko à 6,6 Ko par défaut !

La prudence s’impose néanmoins : mesurez bien l’impact de vos héritages et de vos imbrications car cela peut peser parfois lourd lors de la compilation.

grid.less ?

Il ne tient maintenant plus qu’à vous de produire votre bibliothèque CSS dans un format dynamique. Non seulement vous découvrirez sans doute plein de choses sur la bibliothèque elle-même, mais vous pourrez aussi produire quelque chose qui correspondra parfaitement à vos attentes.

J’ai, pour ma part, fait ce travail (déjà à améliorer, c’est certain) et je vous propose si vous le souhaitez de vous en inspirer : blueprint.less.zip. L’archive est accompagnée d’un petit fichier texte explicatif et inclut déjà quelques media-queries.

La compilation dynamique de vos framework CSS est une solution élégante pour continuer à utiliser les grilles de mise en page encore plus simplement, j’en suis convaincu, j’espère que vous le serez également !

Les ligatures dans les navigateurs

Jeremie — Wed, 06 Apr 2011 09:00:00 +0200

On sait tous que les navigateurs ne sont pas les champions du monde de la gestion typographique. Ceci étant, ils s’améliorent tous les jours et parmi toutes les chipoteries typographiques il y en a une qui commence timidement à faire son apparition dans les navigateurs : la gestion des ligatures. C’est loin d’être parfait, mais il y a déjà moyen de faire quelques petites choses.

La ligature traditionnelle des lettres “f” et “t” de la police Garamond.

C’est quoi une ligature ?

Avant de rentrer dans le vif du sujet, rappelons brièvement ce que sont les ligatures typographiques. Pour faire simple, une ligature typographique consiste à lier [1] deux glyphes pour en former un nouveau. Les ligatures ont évolué au cours de l’histoire de l’écriture puis de la typographie et toutes les langues ne sont pas égales face à cette notion. Par exemple, l’alphabet arabe ou certains alphabets asiatiques en font un usage très important. Ici, je vais me concentrer sur les ligatures des langues reposant sur l’alphabet latin (rien que ça ce n’est déjà pas simple).

Les ligatures des langues en alphabet latin sont, grosso modo, de 4 ordres [2] : les ligatures obligatoires, Les ligatures ordinaires, les ligatures esthétiques et les ligatures spécifiques.

Ligatures obligatoires

Il s’agit de ligatures locales, liées à une langue précise et qui, si elles ne sont pas faites, consistent le plus souvent en une faute d’orthographe. Par exemple, en français, la ligature du « o » et du « e » est obligatoire (« oeil » est une faute, là ou « œil » ne l’est pas). C’est la même chose pour le caractère « ß » (Eszett) en allemand qui est en fait la ligature obligatoire des lettres « s » et « z » [3].

Ligatures ordinaires

Elles sont des ligatures optionnelles (mais vivement recommandées) qui correspondent à des pratiques issues de la typographie au plomb. Elles permettent de résoudre élégamment des problèmes d’esthétique liés à l’approche des caractères. Par exemple, lorsque vous accolez un « T » et un « o », le « o » donne l’impression de flotter car l’espace sous la barre du « T » est vide. Pour corriger ce problème visuel, il faut réduire l’approche entre les deux caractères. Si de nos jours, il est possible de véritablement modifier l’approche entre les caractères, à l’époque du plomb, la seule solution consistait à fondre un seul caractère comportant les deux glyphes « To ». Un autre cas plus épineux se présente si vous accolez un « f » et un « i ». Dans ce cas, l’approche n’a pas nécessairement besoin de changer, mais visuellement, la barre du « f » rentre en collision avec le point du « i ». Pour corriger ce défaut visuel, il est possible de réaliser une ligature en ne créant qu’un seul caractère qui se permet de redessiner le « f » pour faire en sorte qu’il tombe exactement à la place du point du « i » rendant le dessin global plus harmonieux.

C’est quand même mieux une fois que la ligature est réalisée.

Ligatures esthétiques

Ce sont, elles aussi, des ligatures provenant de la typographie traditionnelle au plomb. Par contre, contrairement aux ligatures ordinaires qui résolvent de vrais problèmes visuels, elles ne sont là que pour « faire joli ». C’est par exemple le cas des ligatures « c » et « t » ou bien « s » et « t » (que personnellement j’adore, en particulier sur les serifs).

Ligatures spécifiques

On les appelles également ligatures discrétionnaires : elles sont propres à une police de caractères donnée et ont été créés par le dessinateur de la police à des fin esthétiques spécifiques. En effet, dans l’absolu, toute association de caractères peut faire l’objet d’une ligature et certains dessinateurs de fonte ne s’en privent pas.

Olicana, de Nick Cooke, est une manuaire comportant près de 100 ligatures spécifiques afin de lui donner le naturel d’une véritable écriture manuscrite.

Enfin, historiquement parlant, certains caractères que nous utilisons quotidiennement dans le Web sont en fait des ligatures qui sont passées dans l’usage courant et sont désormais des caractères à part entière. C’est la cas de l’esperluette « & » qui est la ligature de la conjonction « et » et il y des soupçons à propos de l’arobase « @ » qui serait la ligature du latin « ad ».

Comment ça marche techniquement

Donc, les ligatures améliorent la lisibilité et l’esthétique des fontes. En général, en informatique, la gestion des ligatures fait l’objet d’un traitement plus ou moins automatique et cela dépend beaucoup des logiciels qui assurent le rendu typographique. Les navigateurs Web ne font pas exception et ce sont eux qui doivent faire le boulot (souvent en se reposant sur l’OS sous-jacent). Or donc, comment ça marche dans les navigateurs ?

Les ligatures dépendent de la police de caractère…

Eh oui ! Avant même de vous demander si votre navigateur va pouvoir afficher ou non les ligatures, la première chose à faire est de vous assurer que les fontes que vous allez utiliser comportent les éléments nécessaires pour les afficher. Pour faire simple, soit votre police embarque directement les caractères ligaturés soit elle est au format OpenType, TrueType ou WOFF [4] et comporte les instructions spécifiques permettant de gérer les ligatures automatiquement.

Si comme moi vous avez l’habitude d’utiliser le site fontsquirrel.com pour optimiser vos polices pour le Web, faites attention. En effet, si vous décidez de réduire le jeu de caractère de la police, vous perdrez la gestion des ligatures au sein de la police (même si vous demandez expressément à garder les caractères ligaturés, les automatismes de substitution, eux, seront quand même perdus). Donc, si vous voulez pouvoir disposer à la fois du support des ligatures et d’une fonte ne comprenant que les caractères qui vous sont nécessaires, il vous faudra soit vous renseigner au près du fondeur de la police pour obtenir une version Web adaptée à vos besoins, soit, si la licence de la police le permet [5], passer par un logiciel d’édition de fonte pour faire ces optimisations vous-même.

…et du navigateur

Voila, vous êtes sûr que votre police est capable de gérer les ligatures, voyons maintenant comment ça se passe dans le navigateur.

Caractères et entités XML

Un certain nombre de ligatures sont normées au niveau d’Unicode. En conséquence, il est tout à fait possible d’utiliser directement les caractères ou les entités XML correspondants pour les utiliser dans vos texte HTML

<p>Une &#xFB01;lle de cœur</p>

Le problème de cette méthode c’est que d’une part toutes les ligatures ne font pas partie de la norme Unicode et d’autre part, si pour une raison ou une autre, votre police ne comporte pas le caractère correspondant (par exemple, votre fonte déclarée via @font-face ne s’est pas chargée), vous aurez droit à un joli symbole de glyphe introuvable, ce qui n’est pas forcément très heureux ! Personnellement, je vous conseille de n’utiliser cette technique que pour les ligatures obligatoires (comme le « œ » en français).

SVG text-rendering

La norme SVG [6] étend CSS en définissant la propriété text-rendering. Cette propriété permet de dire au navigateur s’il doit privilégier la lisibilité des polices ou bien les performances d’affichage. La norme ne spécifie pas explicitement ce qui améliore la lisibilité ou les performances. Chaque navigateur est libre de faire ce qu’il veut.

Chrome, Safari et Firefox 3.6 sont les premiers navigateurs à gérer l’automatisation des ligatures disponibles dans les fontes OpenType. Ils considèrent également que les ligatures ordinaires servent à améliorer la lisibilité. Ainsi, il est possible d’activer (ou pas) le support des ligatures ordinaires en utilisant cette propriétés CSS.

p {
    text-rendering : optimizeLegibility;
}

<p>Le trafic est fluide.</p>

Dans l’exemple précédent, vous noterez que les ligatures ordinaires « f » et « i » ainsi que « f » et « l » sont bien réalisées mais pas la ligature esthétique « s » et « t ».

Quelques unes des ligatures les plus communes. « ct » et « st » étant esthétiques, elles ne seront pas affichées par défaut dans les navigateurs.

Par défaut, Firefox 3.6 affiche systématiquement les ligatures ordinaires pour tout texte d’une taille supérieure ou égale à 20 px. Donc, si vous voulez explicitement désactiver les ligatures (Ah bon ! Vraiment ?), vous devrez utiliser la propriété text-rendering avec la valeur optimizeSpeed. Dans Chrome et Safari, c’est l’inverse si vous voulez forcer l’affichage des ligatures, vous devrez explicitement utiliser la valeur optimizeLegibility.

Cette utilisation de la propriété text-rendering est largement sujette à caution, et chaque navigateur y va de son interprétation :

Firefox 3.6 l’utilise pour activer ou non les ligatures ordinaires sous Windows et Linux, mais pas sous Mac OSX.
Firefox 4 ne l’utilise plus ! Il affiche toujours les ligatures (sous tous les OS) par défaut et considère qu’il n’est pas possible d’accélérer encore plus l’affichage du texte par rapport à ce qu’il fait déjà et ne tiendra donc pas compte de cette propriété qui sera sans effet. Il ne serait donc pas possible de désactiver les ligatures sous Firefox 4 ? Si, si, j’y viens.
Chrome (10) et Safari (5) fonctionnent comme Firefox 3.6 (si ce n’est mieux), mais uniquement sous Mac OSX et Windows 7. Sous Windows XP, au contraire, cette fonctionnalité est sérieusement buguée [7] : Si vous utilisez @font-face avec une police OpenType et que vous appliquez la propriété text-rendering, votre police ne sera pas affichée si votre texte comporte au moins une espace inter-mot (alors qu’avec une police TrueType, il n’y a aucun problème, mais la qualité de rendu est moindre) !

CSS3 font-feature-settings

Le module CSS3 Font est bien connu pour définir tout le mécanisme des déclarations @font-face, mais il fait bien plus que ça. En effet, il définit également comment les différentes fonctionnalités des polices peuvent être activées ou non.

Je ne rentrerai pas trop dans les détails ici car pour l’instant ce module est en pleine discussion et beaucoup de choses changent quasiment tous les jours à son propos. Néanmoins, il y a une propriété qui est disponible expérimentalement dans Firefox 4 (donc préfixée par -moz-) : font-feature-settings.

Cette propriété permet d’activer ou non l’ensemble des fonctionnalités et effets spéciaux des fontes OpenType un par un. L’exemple ci-après montre comment activer l’ensemble des ligatures possibles dans Firefox 4 :

p {
    -moz-font-feature-setting : "liga=1,clig=1,dlig=1,hlig=1,rlig=1";
}

<p>la star des fillettes.</p>

C’est actuellement le seul moyen de gérer les ligatures dans Firefox 4. À terme, d’autres propriétés CSS3 viendront simplifier l’accès à certaines fonctionnalités : les ligatures, les petites capitales, les glyphes alternatifs, etc. En effet, la propriété font-feature-setting est une propriété générique de « bas niveau » permettant d’accéder à l’ensemble des fonctionnalités OpenType. Il y a donc, parmi d’autres, une proposition pour que les ligatures puissent être gérées indépendamment via une propriété spécifique : la propriété font-variant-ligature.

Au niveau du CSS working group, tout cela est encore hautement volatile et j’aurai l’occasion de vous détailler un peu tout ça dans un futur article quand les choses commenceront à se tasser et à faire consensus (et si possible avec des débuts d’implémentation). Mais pour l’instant, c’est un peu prématuré.

Le pour et le contre

Bon, une fois qu’on s’est dit tout ça, on fait quoi ? Ligature ou pas ligature ?

Comme on l’a vu, techniquement parlant, il est assez difficile de bien contrôler les ligatures que l’on souhaite appliquer à son texte. En particulier, chaque navigateur ayant sa propre approche du sujet, cela ne reste finalement qu’un joli plus mais dont il faudra apprendre à vous passer. Comme souvent sur le Web, il y a trop de facteurs inconnus pour être sûr que l’on contrôle correctement l’affichage. En outre, le Web se caractérise par des choix à faire, parfois difficiles, entre esthétique et performance. Il est, hélas, impossible d’avoir des fontes aussi belles que dans un livre sans en payer le coût en terme de poids des fichiers de police.

Néanmoins, ce serait vraiment dommage de vous passer des ligatures, en particulier sur les titrailles où les glyphes sont visuellement plus « présents » que dans le texte courant. L’esthétique globale des polices en bénéficiera toujours et donc le design de vos pages aussi en général.

Comme d’habitude en termes de web design, je prêche le pragmatisme lié à votre contexte de déploiement (par exemple, les contraintes du « mobile » et du « desktop » sont différentes). Le plus important de mon point de vue (et souvent le plus mal fait) consistant à bien optimiser vos fontes pour le Web (messieurs les fondeurs, si vous nous lisez, ce serait vraiment du bonheur si vous pouviez proposer des outils de construction des fichiers de fonte pour le Web à la demande… si possible accessibles directement en ligne).

Étymologiquement, « lier » et « ligature » ont la même origine, s’il y a des sémiologues parmi vous, faites-vous plaisir dans les commentaires :) [retour]
Amis typographes qui nous lisez, n’hésitez pas à compléter/corriger mes explications superficielles spécial noob dans les commentaires. [retour]
ou « s » et « s », cette ligature a une histoire complexe et je vous invite à lire cet article de Jacques Poitou si vous voulez en savoir plus : http://j.poitou.free.fr/pro/html/typ/allemand.html. [retour]
Par abus de langage, dans la suite de cet article, je ne parlerai plus que du format OpenType car la plupart du temps les formats TrueType et WOFF sont des dérivés d’OpenType. [retour]
Vérifiez bien ce point car c’est souvent très loin d’être le cas. En gros, avec une autre licence que la OFL ou une licence de type BSD/MIT, c’est mort. Même la GPL est problématique dans ce cas là car il vous faudra publier les sources de votre police modifiée. [retour]
Oui, encore elle ! Vous aurez noté que j’aime beaucoup SVG :) [retour]
Ne pas troller, surtout ne pas troller. [retour]

Pourquoi les fontes SVG sont-elles différentes des autres ?

Jeremie — Mon, 07 Feb 2011 09:00:00 +0100

Je suis un peu triste de constater que le format de police SVG est très mal compris. J’ai lu beaucoup d’articles et de récriminations à propos de ce format de police, le dernier d’entre eux étant l’article d’Alexander Limi où il explique pourquoi il n’est pas prévu que Firefox passe le test Acid3, essentiellement à cause d’une absence de support des fontes SVG.

De bien des façons, toutes ces critiques sont déplacées tout simplement parce que ce format de police est incompris. Vraiment ? Mais dans ce cas, à quoi sert-il ? Voyons ça.

Oubliez le texte courant

L’idée fausse, la plus répandue, à propos des fontes SVG, c’est de penser qu’elles sont adaptées au texte courant. Désolé, mais ce n’est pas le cas. À mon sens, cette idée fausse est essentiellement due à Apple. Jusqu’à iOS 4.2, SVG était le seul format disponible pour définir des fontes personnalisées sur iPhone et iPad. Malheureusement, ce support était (est ?) quelque peu approximatif, ce qui a desservi la réputation de ce format de police.

Quoi qu’il en soit, au delà de ce qui existait sur iOS, il est notoire que les fontes SVG ne supportent pas le hinting [1]. Pour bien comprendre ce soit disant « manque », il est important de revenir sur les spécificités du format d’image SVG. Les formes vectorielles d’un document SVG sont placées de manière absolue par rapport à un point de référence unique et le texte dans ces documents ne bénéficie pas d’un système de flux automatique comparable à HTML. En outre, les documents SVG n’ont pas nécessairement une taille ajustée au pixel près et l’ensemble des formes vectorielles peut être sujet à des transformations mathématiques (rotation, changement d’échelle, déformation, etc.). Tout cela fait que les glyphes typographiques peuvent être placés n’importe où, n’importe comment et la plupart du temps ne vont pas se retrouver placés sur une grille calée au pixel près. Dans de tels cas, le hinting, qui ne donne le meilleur de lui-même que lorsque la fonte se retrouve alignée sur une jolie grille, n’a que peu ou pas d’influence sur la qualité du rendu.

Si, par exemple, vous essayez d’appliquer une transformation CSS à un texte rendu avec une police WOFF, vous vous rendrez compte que le hinting ne change visuellement pas grand-chose à la qualité du rendu. Au contraire, si vous appliquez une police SVG sur du texte courant HTML (qui est aligné au cordeau, lui), le texte ne sera pas aussi joli, en particulier avec un petit corps de texte. Donc oui, utiliser les fontes SVG sur du texte courant ce n’est pas terrible. Mais ça tombe bien car ce n’est pas du tout ce pourquoi elles sont faites.

Le pouvoir du dessin

Un des plus gros avantages des fontes SVG par rapport aux autres formats, c’est la façon dont il est possible de dessiner la forme des glyphes. Techniquement parlant, les courbes des fontes SVG peuvent être de n’importe quel type (courbe de Bézier quadratique ou cubique et même définition d’arc de cercle) là où les fontes TrueType n’utilisent que les courbes de Bézier quadratiques. Les fontes OpenType sont un tout petit peu mieux pourvues dans la mesure où elles utilisent les courbes de Bézier cubiques, mais à ma connaissance, seules les fontes SVG supportent la définition d’arc de cercle. Ainsi, en théorie, les formes produites pour les fontes SVG peuvent être bien plus optimisées que dans les autres formats. Ok soyons honnêtes, ce n’est quasiment jamais le cas dès qu’on parle de dessin de fontes classiques. Mais il y a mieux. Puisque les fontes SVG bénéficient de toute la puissance de dessin de SVG, il est possible de dessiner des formes particulièrement complexes en superposant des formes arbitraires et des formes de base (cercle, rectangle, etc.) tout en vous laissant un contrôle très fin sur votre design. Grâce à cela, si vous voulez dessiner une police ornementale, SVG vous offrira des outils bien plus efficaces pour le faire.

D’un point de vue pratique, il est possible d’utiliser n’importe quel logiciel capable de produire du SVG pour dessiner vos polices. Cela inclut les logiciels de création de fontes classiques comme FontForge par exemple, mais également les logiciels de dessin vectoriel comme Adobe Illustrator ou Inkscape (ce dernier ayant des outils intéressants pour le dessin de fontes). Bien sûr, il est possible d’utiliser ces logiciels pour dessiner des formes utilisables dans d’autres formats de police. Néanmoins, vous aurez toujours besoin de les passer à la moulinette d’un logiciel de fontes pour s’assurer que les formes seront définies avec les bons types de courbes (ce qui peut avoir une incidence sur la qualité de votre dessin). Avec SVG, non. Vous pouvez utiliser directement ce qui sort de votre logiciel favori.

Animations, filtres, vidéo… \o/

Allons un peu plus loin. SVG, au-delà de ses capacités de dessin, dispose d’extensions assez impressionnantes telles que les dégradés, les motifs, les découpes, les masques, les animations, les filtres et même la possibilité d’inclure des éléments d’autres langages (HTML, MathML, etc.). Bien sûr, tout est utilisable dans vos polices SVG. Oui, grâce à SVG on peut produire de vraies fontes animées. Grâce aux filtres, il est possible d’imaginer des fontes floutées ou texturées. Et grâce à l’inclusion d’autres langages… Wow ! Il n’y a plus de limite. En effet, pourquoi ne pas imaginer une police ayant un fond sonore ? Oui, c’est possible, il vous suffit juste d’inclure une balise HTML audio et voila.

Bien évidement, ce n’est pas nécessairement une très bonne idée de faire un truc pareil. En particulier si vous prévoyez de l’utiliser sur du texte courant (même si, comme on l’a vu avant ce n’est pas spécialement fait pour ça). Mais réfléchissez-y. Le format de fonte SVG vous permet de vous lâcher d’un point de vue créatif. Dîtes au revoir à la vieille typographie au plomb et allez hardiment là où nul ne s’est aventuré en créant des polices POUR le web (et pas simplement adaptées au web).

Inclusion et arbre DOM

Vous trouvez ça incroyable ? Faisons un pas supplémentaire et entrons dans la 4e dimension.

Il y a 10 ans de ça, le format de fonte SVG était le seul format qui pouvait être embarqué directement au sein d’un document SVG. Cette fonctionnalité était nécessaire pour s’assurer que les polices d’un document seraient affichées de manière cohérente quel que soit le système de rendu, navigateur ou autre. Aujourd’hui, grâce au module @font-face de CSS associé avec les Data URI, il est possible d’embarquer n’importe quel type de format de police. Néanmoins, SVG garde encore un petit avantage ici.

Comme vous le savez, SVG est un format XML et donc, les fontes SVG le sont également. Cela signifie que vous pouvez inclure directement votre police dans n’importe quel document XML (par exemple, une image SVG, bien sûr, mais également dans un document XHTML ou, dans un futur proche, grâce à HTML5, dans n’importe quel document HTML) et continuer d’avoir accès aux glyphes via l’arbre DOM du document XML. Et ça, c’est énorme car vous pouvez alors faire deux choses :

Vous pouvez accéder au contenu des polices via Javascript et le changer comme vous voulez. Le format de fonte SVG vous donne un contrôle total sur chacun des glyphes à tous moment.
Vous pouvez utiliser CSS pour changer le style de chaque glyphe individuellement ce qui vous donne un contrôle incroyable sur la manière dont vos polices vont être affichées.

Aucun autre format de fonte ne permet un accès aussi facile et complet aux glyphes et à leur dessin.

Sécurité, accessibilité, bla, bla, bla…

Avec un tel pouvoir, vous héritez des responsabilités qui vont avec. La sécurité est un sujet important dès que l’on parle des fontes SVG. Comme le fait remarquer Borris Zbarsky : À l’instant où vous mettez une <iframe> dans un glyphe, tout un tas de problèmes se présentent et il a sacrément raison. Ce sujet doit effectivement être discuté, mais est-ce une raison pour jeter bébé avec l’eau du bain ? Personnellement, je ne crois pas.

L’accessibilité est un autre point chaud. Avec des fontes aussi malléables, bon nombre de questions se posent. Par exemple, « Comment un utilisateur peut-il contrôler les animations au sein d’une police de caractère ? ». Mais toutes ces questions sont fondamentalement les mêmes que celles que posent le format SVG en général. De fait, il est possible de s’appuyer sur les solutions existant aujourd’hui pour SVG.

Bien évidement, il est nécessaire que les fabriquants de navigateurs et les web designers fassent attention à ces contraintes. Oui, c’est vrai, des créateurs malveillants feront n’importe quoi avec les fontes SVG. Oui, c’est vrai, tous les fabriquants de navigateurs (oui, tous) ne mettent pas beaucoup de bonne volonté à supporter ce format. Ainsi soit-il ! Ceci étant, je pense que les fontes SVG sont un vrai tournant dans l’histoire de la typographie et qu’elles devraient être prises pour ce qu’elles sont : un outil incroyable pour apporter un nouveau souffle graphique à la typographie et une opportunité pour donner des polices vraiment adaptées au design pour le web. Et surtout, il faut se souvenir que les fontes SVG n’ont pas le même usage que les fontes WOFF sur le Web. Chacun de ces formats a ses avantages et ses inconvénients mais ils ne sont finalement pas mutuellement exclusifs.

Si vous avez une bonne traduction de « hinting », je suis preneur. [retour]

La justification sur le web : usages et précautions

Anne-So — Mon, 31 Jan 2011 14:07:00 +0100

Les lecteurs nous demandent souvent comment faire pour avoir une chevelure aussi souple et brillante que nous [1], mais ils nous interrogent aussi régulièrement sur un parti pris du design de notre site qui contrevient aux principes qu’ils connaissent : la justification au pavé du texte courant.

Gustave Courbet découvrant du texte justifié sur un site prétendument ami de la typographie.

Effectivement, on dit et on répète depuis longtemps (enfin, pas trop longtemps non plus puisque tout cela ne date que d’avant-hier) qu’il ne faut pas justifier le texte sur le Web, qu’il faut s’en tenir à une composition en drapeau. Les raisons à cela sont bonnes parce qu’elles résident dans une caractéristique du support Web : la pauvreté des paramètres d’ajustement de l’espace dans un texte.

L’interface de paramétrage de la justification dans InDesign (j’ai bien vu que c’était en anglais ; je pense que ça reste explicite quand même).

Lorsqu’on compose du texte au pavé, que ce soit en typographie au plomb ou dans InDesign, on peut couper les mots en fin de ligne [2], modifier l’espace qui sépare les mots [3], voire ajuster légèrement celui qui sépare les lettres [4], afin d’obtenir une répartition harmonieuse du texte, sans lézardes ni blancs disgracieux. On réserve la justification au pavé aux lignes suffisamment longues car il est impossible d’obtenir quelque chose d’uniforme en n’ayant que quelques mots par ligne : vous avez sans doute déjà vu ces affreuses colonnes étroites de texte justifié où parfois les mots sont tout bonnement écartelés pour occuper tout l’espace disponible – et vous avez pleuré des larmes de sang.

Les contraintes techniques du Web

Sur le Web, le seul paramètre d’ajustement est l’espace-mot, que le navigateur étend de façon à ce que chaque ligne occupe toute la largeur du bloc si vous avez spécifié text-align: justify;. Il est évident que ça ne suffit pas. Si l’on manipule uniquement l’espace mot, le risque est grand que des blancs très moches apparaissent partout dans le texte (d’ailleurs, si vous plissez les yeux, vous y verrez apparaître le visage de Satan). La propriété letter-spacing ne permet pas de définir la tolérance d’élasticité de l’espace interlettres comme dans un logiciel de composition, mais uniquement à modifier ponctuellement et uniformément l’approche d’un mot ou d’un groupe de mot, dans un titre tout en capitales par exemple.

Il semble donc évident qu’actuellement, il est impossible de composer du texte au pavé correctement sur le Web. De plus, ce support est par nature fuyant et imprévisible, ce qu’il faut comprendre comme « Par principe, tout est susceptible d’être bien pire que ce qu’on imagine ». C’est le monde merveilleux du worst-case scenario. Tout le monde s’est ainsi tacitement ou ouvertement mis d’accord pour renoncer définitivement à justifier du texte sur le Web, puisque ça allait créer des rivières larges comme le Saint-Laurent et introduire des blancs tellement grands entre les mots qu’on ne verrait plus qu’ils sont sur la même ligne.

Le fleuve Saint-Laurent à la hauteur de Tadoussac. Effectivement, on ne voit pas l’autre rive. C’est ça l’Amérique, tout est plus grand.

Certes, beaucoup de facteurs doivent être réunis pour que la justification au pavé fonctionne sur le Web. Le bloc doit être suffisamment large (autour de 60 caractères pour un texte en français). Vous aurez en outre plus de chances avec une langue contenant beaucoup de mots courts comme l’anglais. Le choix des caractères joue également beaucoup : si vos caractères sont étroits [5] et que leur approche est faible, chaque mot a une apparence compacte qui contraste plus fortement avec le blanc de l’espace-mot. Lorsque le navigateur agrandit cette dernière [6] pour justifier le texte, cela se voit beaucoup plus que si vos caractères sont larges et que le mot a une apparence plus aérée. Si vous choisissez de justifier le texte, votre chaîne de substitution de fontes CSS devra tenir compte de cet aspect.

D’autre part, il existe des outils qui permettent de contourner les limitations du Web, notamment un bidule en JavaScript qui gère automatiquement la césure, dans le respect de la langue du texte : hyphenator.js. Le résultat est assez spectaculaire : la césure se fait de façon dynamique côté client en fonction de la largeur du bloc, et les tirets disparaissent si vous copiez et collez du texte. Toutefois, ce script n’offre pas les réglages disponibles dans InDesign, par exemple, pour limiter le nombre de césures successives ou spécifier le nombre de caractères minimum devant précéder la césure ou lui succéder. Cette solution est donc loin d’être idéale, même si elle peut apporter un mieux certain d’un point de vue visuel.

À titre de comparaison, l’interface de paramétrage de la césure dans InDesign, encore en anglais.

Un peu d’accessibilité aussi

Au-delà des considérations esthétiques, dès que l’on parle de Web, les notions d’accessibilité ne sont pas loin. À cet égard, la composition au pavé est souvent mise à l’index car elle aurait le défaut d’être plus difficile à lire d’un point de vue cognitif. Ce grief n’est pas nouveau est existe déjà dans la composition classique des livres. Malheureusement, il est amplifié sur le Web car, comme nous l’avons vu ci-avant, seul l’espace-mot varie, et parfois de manière significative si l’on n’y prend pas garde. Or, cela peut être problématique dans certains cas de dyslexie par exemple [7].

Mais sans en arriver jusque là, il peut être plus difficile de lire un texte au pavé si les lignes sont trop longues, l’œil pouvant alors avoir du mal à passer d’une ligne à l’autre (il peut glisser en sautant une ligne ou bien rester sur la même ligne). En fait cela tient aussi beaucoup à la nature du Web qui offre un cadre beaucoup moins rigide que le papier. Ainsi, l’œil dispose de moins de points de repère stables sur lesquels s’appuyer lors de la lecture. Donc selon le contexte de la mise en page, la composition au carré peut renforcer les lignes de force verticales de votre mise en page (ce qui va accentuer l’effet de « ratage de ligne ») ou au contraire asseoir les lignes de force horizontales qui vont apaiser la lecture. Ah oui, si vous avez cru qu’il y aurait une réponse facile du type « c’est bien », « c’est mal »… désolé, mais notre élevage de bisounours n’est pas encore un franc succès.

Dans le même ordre d’idée, mais sur un aspect plus technique, les outils qui vont compenser les manques des navigateurs, comme hyphenator.js ou lettering.js, ne doivent pas être utilisés les yeux fermés sans un minimum de précautions. En effet, ces outils peuvent complètement modifier ou simplement perturber l’arbre DOM des documents, ce qui peut avoir un effet non négligeable sur tout les outils d’aide à l’accessibilité qui reposent sur le DOM (certaines revues d’écran par exemple). Donc, prudence, modération et sens du « lâcher prise » sont toujours de rigueur.

Ite missa est

L’Histoire avec un grand i nous a maintes fois prouvé que les dogmes entraînent souvent des bains de sang et qu’il est donc préférable de les remettre en question tout de suite avant qu’ils ne s’installent. De plus, l’interdit qui pèse sur la justification s’apparente furieusement à un principe de précaution, dont les débordements ont les conséquences que l’on sait dans notre société malade. Je vous propose autre chose : faites preuve de bon sens, essayez, vous saurez tout de suite si ça marche.

Sur ce site, le texte est justifié parce que j’ai essayé pour voir et que j’ai été toute étonnée de voir que ça marchait. Je me suis dit que j’allais devoir faire preuve d’une grande diplomatie pour faire passer ça auprès des autres, qui m’ont en fait répondu : « Ah ouais c’est vrai ça marche, et c’est mieux, chic alors » [8]. Le résultat n’est pas parfait, mais nous avons jugé que nous préférions les imperfections de la justification au déséquilibre de la composition en drapeau, dans la mesure où les imperfections ne nous semblaient pas faire obstacle à la lisibilité du texte. C’est une affaire de choix, de priorité et de bon sens.

Faites-vous confiance, bon sang. Si vous connaissez les principes et leurs raisons, alors c’est votre œil qui doit avoir le dernier mot.

Les notes de cet article et la section sur l’accessibilité vous sont gracieusement offertes par Jérémie

Oui, mais alors moi je sors du coiffeur et j’ai les cheveux courts… comment ça ce n’est pas le sujet ? Non, mais… je… bon, ok. [retour]
Le terme typographique c’est : césure [retour]
Là, on parle d’espace-mot [retour]
Et là il s’agit de l’approche et plus précisément de l’interlettrage [retour]
Cette fois le terme technique c’est : la chasse… qui n’a rien à voir avec de petits animaux à plume ou poils ni même avec un petit poney. [retour]
Oui, c’est un peu comme la mort chez Terry Pratchett qui est de genre masculin, en typographie l’espace est de genre féminin. [retour]
A ce sujet je vous invite à lire cet article en 3 partie de Mel Pedley : Designing for dyslexics [retour]
Oui mais en fait, on a tendance a être pas mal d’accord sur plein de trucs, surtout lorsqu’il s’agit de faire preuve de modération et d’esprit critique. [retour]

Maîtriser le délai d'affichage des fontes

Jeremie — Mon, 24 Jan 2011 09:30:00 +0100

Avez-vous remarqué que lorsque vous utilisez une déclaration @font-face avec un navigateur qui utilise le moteur de rendu Webkit (Safari, Chrome) ou bien avec Internet Explorer votre texte n’est affiché qu’une fois que la police est téléchargée ? En surfant confortablement assis avec une connexion ADSL, on ne s’en rend pas bien compte. Par contre, lorsqu’on utilise un téléphone ou une tablette qui tourne sous iOS ou Androïd, ce n’est pas rare.

De leur côtés, Firefox et Opera ont une autre approche : ils affichent le texte à l’aide des fontes de substitution déclarées dans les feuilles de style et modifient le rendu des polices une fois que celles-ci ont été chargées. Cela peut provoquer un clignotement un peu disgracieux mais au moins, si votre réseau est lent (ce qui est souvent le cas avec les réseau de téléphonie mobile) vous pouvez toujours commencer à lire le texte.

Avantages et inconvénients des deux solutions

Ces deux manières de gérer l’affichage des polices personnalisées fait l’objet d’un débat assez virulent chez les web designers anglo-saxons. Il est difficile, voire impossible de départager les deux camps car les avantages des uns sont les inconvénient des autres et réciproquement. Mais de quoi parle-t-on exactement ?

Afficher les fontes uniquement après leur chargement

Le principal avantage de cette technique est que vous avez un meilleur contrôle de votre design. Vous ne risquez pas de vous retrouver avec une fonte toute moche à la place de votre police d’origine. Par contre, si par malheur votre police met du temps à se télécharger, il n’y a rien à lire.

Afficher les fontes de substitution en attendant le chargement

De l’autre coté, afficher le texte avec les polices de substitution prévues dans la chaîne CSS permet au navigateur d’afficher le texte dès que possible, même si la fonte personnalisée n’est pas encore là. Par contre selon la vitesse de chargement, vous allez exposer vos visiteurs à un effet de clignotement somme toute assez disgracieux.

Et c’est quoi le mieux ?

Difficile à dire et il n’y a pas de réponse absolue à cette question. Certains pensent que ce n’est qu’un détail anodin, et je ne leur donnerai pas tort dans la mesure où une fois que la police a été téléchargée, si le navigateur l’a correctement mise en cache, les prochains chargements de page ne souffriront plus ni d’un clignotement ni d’une absence de rendu.

À titre personnel, je suis plutôt partisan de la méthode choisie par Firefox et Opera. En effet, le Web est un milieu hostile où l’on ne maîtrise pas les conditions de rendu ni la latence réseau. En conséquence je préfère être sûr que mes visiteurs pourront lire le texte plutôt que d’être sûr que celui-ci sera joli (mais si je peux avoir les deux, je préfère encore plus). Ceci étant, si vous construisez des sites où le design est primordial et où le contenu textuel n’est qu’un soutien graphique, il est effectivement souhaitable d’avoir un comportement comme celui de Safari, Chrome ou Internet Explorer. Ah ! Cruel dilemme.

Limiter le clignotement

Allons courage, il n’y a pas de fatalité, et il est possible de réduire les inconvénients liés à l’une ou l’autre des solutions d’affichage. D’abord voyons comment limiter l’effet de clignotement de Firefox et Opera.

Bien choisir votre chaîne de polices CSS

La première chose à faire pour réduire l’effet de clignotement c’est de choisir avec soin la liste des polices typographiques à déclarer dans la propriété CSS font-family.

Assurez-vous que le dessin des polices est proche (évitez de déclarer une fonte manuaire avec une fonte de substitution de type linéal)
Assurez-vous que la hauteur d’x de chacune des polices est équivalente. Le clignotement perçu sera plus important avec un changement de hauteur d’x plutôt qu’avec un changement de chasse.

/* A éviter */
p {
    font-family : "Garamond", sans-serif;
}

/* C'est mieux */
p {
    font-family : "Garamond", "Times New Roman", Times, serif;
}

Harmoniser les hauteurs d’x

Comme je vous le disais, c’est le changement de hauteur d’x qui est le plus perturbant lorsqu’une fonte est substituée à une autre. Pour harmoniser les hauteurs d’x, vous pouvez utiliser la propriété CSS font-size-adjust. Cette propriété fait partie du module “CSS3 Font”. Malheureusement, à ce jour, seul Firefox l’implémente.

Cette propriété permet d’ajuster la taille des fontes de manière à ce que chacune des polices déclarées dans la propriété font-family ait la même hauteur d’x apparente. La valeur de cette propriété est un nombre décimal, à vous de voir quelle est la valeur la plus adaptée à votre chaîne de déclaration de fonte. Il n’y a malheureusement pas de recette miracle ici… il faut tester.

/* C'est beaucoup mieux */
p {
    font-family : "Garamond", "Times New Roman", Times, serif;
    font-size-adjust : 0.5;
}

Choisir le comportement que l’on veut.

L’idéal, ce serait de pouvoir choisir le comportement que l’on souhaite selon les cas d’utilisation. S’il existe beaucoup de ressources qui expliquent comment faire en sorte que Firefox réagisse comme Safari et Chrome, il est par contre beaucoup plus difficile de trouver comment faire l’inverse.

Les équipes de Google et de Typekit ont travaillé dur sur la question et proposent une solution assez élégante à base de Javascript qui vous permet de choisir le comportement de votre choix : Web Font Loader. Cette bibliothèque Javascript vous permet de contrôler très finement le chargement de vos polices et leur affichage. Son utilisation est des plus simples.

Tout d’abord, il vous faut une feuille de style qui comporte uniquement vos déclarations @font-face (vous pouvez aussi faire appel directement aux feuilles de style fournies par certains services de fontes comme FontDeck ou Google Font Directory)

@font-face{
    font-family : "maFonte";

    src : url('maFonte.eot');

    src : local('☺'),
          url('maFonte.woff') format('woff'),
          url('maFonte.svg#abcd') format('svg'),
          url('maFonte.ttf') format('truetype');
}

Ensuite, il vous faut appeler cette feuille de style via le script Web Font Loader

<script>
WebFontConfig = {
    custom: { families: ['maFonte'],
              urls: [ 'http://yourwebsite.com/styles.css' ] }
};
 
(function() {
    var wf = document.createElement('script');
    wf.src = ('https:' == document.location.protocol ? 'https' : 'http') + '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
    wf.async = 'true';
    var s = document.getElementsByTagName('script')[0];
    s.parentNode.insertBefore(wf, s);
})();
</script>

De cette manière, le chargement des polices va être monitoré par le script qui va, selon l’état du chargement (en cours, terminé ou échoué, globalement ou bien fonte par fonte), attacher des classes à votre page HTML, ce qui va vous permettre de choisir le comportement que vous voulez simplement via CSS.

En admettant que votre chaîne de déclaration de fonte soit la suivante

p {
    font-family : "maFonte", Arial, sans-serif;
}

Pour toujours avoir un comportement comme celui de Safari il faut rajouter la règle suivante :

.wf-mafonte-n4-loading p {
    visibility:hidden;
}

Pour toujours avoir un comportement comme celui de Firefox il faut rajouter la règle suivante :

.wf-mafonte-n4-loading p { 
    font-family : Arial, sans-serif;
}

Conclusion

Que vous soyez pro Safari ou pro Firefox peu importe, désormais vous êtes équipé pour contrôler le chargement de vos fontes. Dans tous les cas, je vous encourage à toujours penser à vos utilisateurs et à tester au maximum les différents contextes d’utilisation pour vous rendre compte de ce qui se passe. Tout le monde n’a pas le dernier navigateur à la mode associé à une connexion haut-débit.

Bonnes pratiques pour les déclarations @font-face

Jeremie — Tue, 04 Jan 2011 09:00:00 +0100

De vous à moi, je crois qu’on peut se le dire, 2010 aura été l’année du retour en force des polices typographiques embarquées dans les navigateurs. Les déclarations @font-face fleurissent un peu partout, et nous ne nous en plaindrons pas. Ceci dit, la compatibilité multi-navigateur de ces déclarations est parfois un peu problématique. Voyons comment s’en sortir techniquement parlant.

Petit rappel historique

À l’origine, les déclarations CSS @font-face faisaient partie de la norme CSS 2.0 et étaient supportées aussi bien par Internet Explorer 6 que par Netscape 4. Nous étions alors à la fin des années 90 et la guerre entre ces deux navigateurs faisait rage. Malheureusement, les constructeurs ainsi que les fondeurs ne parvinrent pas à se mettre d’accord à l’époque sur un format de fonte et le haut débit n’étant pas encore généralisé, cette technologie ne fut que peu ou pas utilisée. En conséquence, lors de l’écriture de la norme CSS 2.1, cette fonctionnalité fut purement et simplement supprimée.

Avec CSS 3, c’est le grand retour en force des fontes web à travers le module CSS Fonts qui redéfinit la méthode d’insertion des fontes personnalisées dans les navigateurs. Les spécifications c’est bien, mais comme d’habitude avec CSS, il faut voir au cas par cas ce que cela donne avec les différents navigateurs.

Déclaration simplifiée

Une déclaration simple ressemble à ça :

@font-face{
    font-family : "maFonte";
    src : url('maFonte.ttf');
}

La propriété font-family permet de définir le nom de la fonte tel qu’il sera utilisé par la suite dans les déclarations de style. La propriété src quant à elle permet de spécifier le fichier source de la fonte qui sera utilisé par le navigateur pour rendre la police. L’utilisation de la police se fera très simplement de la façon suivante :

p {
    font-family : "maFonte", Helvetica, Arial, sans-serif;
}

Gestion des formats de fonte

Le problème de l’exemple précédent, c’est qu’il ne fonctionnera qu’avec les navigateurs qui supportent les polices au format TrueType. Hélas, tous les navigateurs ne supportent pas ce format particulier. Donc, pour vous assurez que votre rendu typographique sera cohérent [1] entre les divers navigateurs, vous devez proposer vos fontes dans un format compréhensible par chacun d’entre eux. Si ce n’est pas possible, les règles de la cascade CSS s’appliqueront et, dans le cas de l’exemple précédente le texte s’affichera alors en Helvetica, Arial ou, en dernier ressort, dans la fonte sans empattement par défaut disponible.

Il n’y a qu’une seule façon de déclarer plusieurs fichiers alternatifs pour une même fonte, c’est en séparant les déclarations d’url par une virgule (pratique assez courante avec CSS3).

@font-face{
    font-family : "maFonte";
    src : url('maFonte.woff') format('woff'),
          url('maFonte.svg#abcd') format('svg'),
          url('maFonte.ttf') format('truetype');
}

Comme vous pouvez le voir, la propriété src requiert l’url d’un fichier de fonte et peut comporter une déclaration de format. Déclarer le format permet de dire explicitement aux navigateurs le type de fonte qui se cache derrière l’url d’un fichier. La déclaration de format n’est pas obligatoire mais si vous ne la rajoutez pas, le navigateur va devoir télécharger la fonte pour vérifier son format, ce qui du point de vue des performances (et donc du rendu de vos polices) peut être vite catastrophique.

Notez la présence de l’ancre nommée sur l’url de la police SVG. Il est nécessaire pour Safari afin de lui dire explicitement où, dans le fichier SVG, se trouve la déclaration de police. À première vue, ça peut paraitre un peu idiot, mais il faut se rappeler qu’un fichier SVG peut contenir bien d’autres choses que des polices de caractères ou bien en contenir plusieurs.

Notez également, l’ordre de déclaration des formats : d’abord WOFF, puis SVG et enfin TrueType. Il est important de respecter cet ordre-ci car certains navigateurs savent utiliser plusieurs de ces formats. Or ils utiliseront le premier qu’ils comprennent dans la liste. Il est donc important de bien déclarer vos formats du plus léger au plus lourd pour des questions de performances (SVG est plus léger que TrueType si vous faîtes attention à le servir en version compressée).

Le cas Internet Explorer

Le type de déclaration vu précédemment va marcher avec tous les navigateurs sauf Internet Explorer (ne riez pas). Certes d’une part cette déclaration ne comporte pas le seul format connu par IE (le format EOT) mais de toute façon, IE ne comprend pas la syntaxe CSS3, à base de déclarations multiples séparées par des virgules, utilisée pour la propriété src. Néanmoins, on peut facilement utiliser les règles de la cascade CSS pour fournir un fichier alternatif pour IE.

@font-face{
    font-family : "maFonte";

    /* pour IE */
    src : url('maFonte.eot');

    /* pour les autres */
    src : url('maFonte.woff') format('woff'),
          url('maFonte.svg#abcd') format('svg'),
          url('maFonte.ttf') format('truetype');
}

Mais même comme cela ce n’est toujours pas suffisant. En effet, malgré les règles de la cascade CSS, IE souffre d’un bug qui va le pousser à essayer de comprendre la deuxième déclaration src et il va donc envoyer une requête HTTP vers : maFonte.woff)%20format('woff'),%20url(m [...] tf)%20format('truetype ! Je sais, c’est assez surprenant, mais il y a longtemps que j’ai appris à ne plus m’étonner des bugs de IE.

Attention, ce qui suit sur la fonction local() n’est plus d’actualité, reportez vous à la mise à jour en fin d’article pour en savoir plus

Pour résoudre ce problème, il suffit d’utiliser l’appel aux fontes locales via la fonction CSS local(). Cette fonction CSS permet de dire à un navigateur d’aller chercher une police dans la liste des polices locales installées sur la machine de l’utilisateur

@font-face{
    font-family : "maFonte";

    src : url('maFonte.eot');

    src : local('maFonte'),
    url('maFonte.woff') format('woff'),
    url('maFonte.svg#abcd') format('svg'),
    url('maFonte.ttf') format('truetype');
}
Voila, comme IE ne connait pas la fonction local(), il va considérer que la deuxième déclaration n’est pas valide pour lui et, en respectant la cascade CSS, il va se rabattre sur la première déclaration qui, elle, est valide pour lui. Oui, mais nos ennuis ne sont pas tout à fait finis.

Le problème avec les appels aux fontes locales, c’est que rien ne vous garantit que la police locale corresponde bien à celle que vous voulez utiliser. Donc, si vous voulez garder un minimum de contrôle sur l’affichage de vos polices typographiques, il faut vous assurer d’appeler une police locale qui n’existe pas. Le problème vient du fait que d’une part, n’importe quelle suite de caractères peut faire référence à une police installée localement, et d’autre part, la fonction local() doit impérativement contenir une chaine de caractères. Heureusement, la solution vient cette fois d’une restriction existant chez les Mac. En effet, la spécification OpenType définie clairement que la plate-forme Macintosh d’Apple ne peut pas avoir de fonte nommée sur 2 bytes. Il est donc hautement improbable qu’une police ait un jour un nom aussi court. On peut donc utiliser n’importe quel caractère Unicode codé sur 2 bytes pour définir un appel à une fonte locale qui n’existe pas. Et tant qu’à faire, puisque tout marche enfin, pourquoi ne pas utiliser ce caractère : ☺

@font-face{
    font-family : "maFonte";

    src : url('maFonte.eot');

    src : local('☺'),
    url('maFonte.woff') format('woff'),
    url('maFonte.svg#abcd') format('svg'),
    url('maFonte.ttf') format('truetype');
}

Les alternatives

Maintenant qu’on s’en est sorti avec les différents formats de fontes, vous avez peut-être envie de gras et d’italique ? @font-face permet de déclarer ces alternatives de manière explicite, mais tous les navigateurs ne les gèrent pas correctement.

La manière la plus simple de gérer vos alternatives consiste à avoir une déclaration @font-face pour chaque police avec un nom différent.

@font-face{
    font-family : "maFonte";

    src : url('maFonte.eot');
    src : local('☺'),
          url('maFonte.woff') format('woff'),
          url('maFonte.svg#abcd') format('svg'),
          url('maFonte.ttf') format('truetype');
}

@font-face{
    font-family : "maFonteGras";

    src : url('maFonteGras.eot');
    src : local('☺'),
          url('maFonteGras.woff') format('woff'),
          url('maFonteGras.svg#abcd') format('svg'),
          url('maFonteGras.ttf') format('truetype');
}

p {
    font-family : "maFonte", Helvetica, Arial, sans-serif;
}

p strong {
    font-family : "maFonteGras", Helvetica, Arial, sans-serif;
    font-weight : normal;
}

Le problème de cette approche, c’est que si vous êtes dans un contexte où vous ne maîtrisez pas absolument votre style (avec un CMS par exemple) vous pouvez vous retrouver avec des polices affichées avec des faux gras ou des faux italiques, ce qui est généralement assez moche. D’un autre côté, dans l’exemple de code précédent, si pour une raison ou une autre, la police myFonteGras n’est pas chargée, vous perdez le gras sur les polices de substitution.

Heureusement, @font-face dispose d’un mécanisme de gestion des alternatives assez simple pour résoudre ces questions. Il vous suffit de rajouter les propriétés font-weight (pour le gras) font-variant (pour les petites capitales) et font-style (pour l’italique) dans vos déclarations.

@font-face{
    font-family : "maFonte";

    src : url('maFonte.eot');
    src : local('☺'),
          url('maFonte.woff') format('woff'),
          url('maFonte.svg#abcd') format('svg'),
          url('maFonte.ttf') format('truetype');

    font-weight:normal;
    font-style:normal;
    font-variant:normal;
}

@font-face{
    font-family : "maFonte";

    src : url('maFonteGras.eot');
    src : local('☺'),
          url('maFonteGras.woff') format('woff'),
          url('maFonteGras.svg#abcd') format('svg'),
          url('maFonteGras.ttf') format('truetype');

    font-weigth : bold;
}

Normalement, vous ne devriez pas avoir besoin de déclarer les variantes normal, mais il s’avère que cela est nécessaire pour Safari et Chrome qui, sinon, ont du mal à gérer les alternatives. En fait, de manière générale, cette méthode est encore très buggée dans la plupart des navigateurs et pas du tout supportée par Internet Explorer. C’est donc à vous de voir dans quels cas de figure vous tolérerez du faux gras ou du faux italique ou pas.

Conclusion

Le support de @font-face étant ce qu’il est à l’heure actuelle, il restera toujours nécessaire de faire des tests multi-navigateurs pour s’assurer du bon rendu de vos polices typographiques. Ceci étant, avec le contenu de cet article vous avez un terrain solide sur lequel vous reposer. De manière générale, je vous invite à utiliser le générateur de fontes du site fontsquirrel.com qui vous permet de packager vos polices pour le web aux petits oignons et qui vous générera en plus les déclarations de styles qui vont bien.

Cet article est fortement inspiré des articles de Paul Irish sur le même sujet. Si vous voulez plus de détails sur les contraintes techniques qu’imposent chaque navigateur en terme de support de @font-face je ne saurais trop vous recommander d’y jeter un coup d’œil :

Une autre excellente ressource à lire, l’article de Tim Brown (en anglais) : How to use CSS @font-face

MAJ du 4 Fevrier 2011

Depuis que j’ai écris cet article, des bugs on été trouvés liés à l’usage de la fonction local() sous Androïd et donc, cette méthode de déclaration n’est plus recommandée. Heureusement, des solutions ont été trouvé pour résoudre ce souci. Dans un premier temps, les principaux fournisseurs de fontes en ligne se sont rabattus sur la solution que proposait Richard Fink qui marche très bien mais est un peu “moche”. Néanmoins, les gens de chez FontSpring ont trouvé une solution à la fois plus élégante et vraiment passe partout :

@font-face{
    font-family : "maFonte";

    src : url('maFonte.eot'); /* Pour IE9 Compat mode */
    src : url('maFonte.eot?') format('eot),
          url('maFonte.woff') format('woff'),
          url('maFonte.svg#abcd') format('svg'),
          url('maFonte.ttf') format('truetype');
}

Comme je l’explique ci-avant, les version d’Internet Explorer 6, 7 et 8 souffrent d’un bug de parsing qui leur font croire que l’adresse de la fonte est la chaine de caractère comprise entre la première parenthèse ouvrante et la toute dernière parenthèse fermante de la déclaration src. Le coup de génie de FontSpring a été de rajouter un “?” à la fin de l’adresse de la fonte EOT. De cette manière, les vieilles versions de IE vont bien charger le fichier de police et tout ce qui sera après le “?” ne servira à rien mais évitera un appel vers une adresse qui n’existe pas puisque ce sera compris comme étant un paramètre d’URL.

Vous noterez qu’il est requis de préciser le format des fontes, y compris celui de la fonte EOT pour que les autres navigateurs ne la charge pas “pour voir s’ils la comprennent”. Par contre, ce qu’il faut savoir, c’est que le vrai nom de format pour les fontes EOT, ce n’est pas “eot” mais “embedded-opentype”. Pourquoi ne pas utiliser le vraie nom de format me diriez-vous ? Et bien c’est tout simplement pour IE9. En effet, IE9 peut utiliser aussi bien les fontes EOT que les fontes WOFF. Si vous voulez qu’il utilise les fontes WOFF, vous devez faire en sorte qu’il ignore la fonte EOT. Comme IE9 comprend les déclarations de fichier multiple de la propriété src, il suffit juste de fournir un nom de format qu’il ne comprendra pas pour la fonte EOT et il passera alors à la fonte suivante dans la liste, à savoir dans ce cas, la fonte WOFF.

Enfin, à peu près cohérent, je ne vous parlerai pas ici des différents types de rendu typographique qui peuvent fortement varier selon le moteur de rendu utilisé, qui change en fonction des différentes combinaisons : navigateur + OS. [retour]

Macro-typographie sur le Web - Mise en pratique

Vincent — Thu, 16 Dec 2010 10:29:00 +0100

Vous êtes convaincu par l’utilisation des grilles typographiques ? Voilà qui fait plaisir.

Nous avons choisi dans le billet précédent nos outils et il ne reste donc plus qu’à passer à la pratique !

Mise en place du modèle

Vous avez peut-être déjà un modèle personnalisé tout prêt que vous utilisez pour débuter vos intégrations. Si ce n’est pas le cas, créez un document HTML basique de ce type.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
    <head>
        <!--[if IE]><![endif]-->
        <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
        <title> </title>    
    </head>
    <!--[if gte IE 8]><body class="ie ie8">    <![endif]-->
    <!--[if IE 7]>    <body class="ie ie7">    <![endif]-->
    <!--[if IE 6]>    <body class="ie ie6">    <![endif]-->
    <!--[if !IE]>-->  <body class="not-ie"><!--<![endif]-->

        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>
    </body>
</html>

Je déplace par habitude les fichiers utiles de travail à Blueprint dans le répertoire CSS. Je les lie ensuite simplement à mon fichier HTML.

On liste :

la CSS destinée à l’affichage écran ;
la CSS destinée à l’impression ;
la CSS destinée aux correctifs pour Internet Explorer.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
    <head>
        <!--[if IE]><![endif]-->
        <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
        <title> </title>

        <!-- Blueprint -->
        <link rel="stylesheet" type="text/css" href="http://typographisme.net/post/css/screen.css" media="screen" />
        <link rel="stylesheet" type="text/css" href="http://typographisme.net/post/css/print.css"  media="print"  />
        <!--[if lt IE 8]>
        <link rel="stylesheet" type="text/css" href="http://typographisme.net/post/css/ie.css"     media="screen" />
        <![endif]-->

    </head>
    <!--[if gte IE 8]><body class="ie ie8">    <![endif]-->
    <!--[if IE 7]>    <body class="ie ie7">    <![endif]-->
    <!--[if IE 6]>    <body class="ie ie6">    <![endif]-->
    <!--[if !IE]>-->  <body class="not-ie"><!--<![endif]-->

        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>
    </body>
</html>

Habituellement, je concatène les deux fichiers screen.css et print.css grâce aux medias queries. J’économise ainsi une requête. Veillez cependant à placer les instructions destinées à l’impression en fin de fichier pour que cela marche sans souci sous Internet Explorer.

J’en profite ensuite pour installer #grid auquel j’ajoute une feuille de style. Je prends le soin de commenter mon code pour préciser qu’il ne doit pas se retrouver dans un environnement de production.

Notez que #grid nécessite également l’utilisation de jQuery (que je chargeais déjà dans mon template initial).

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fr" lang="fr">
    <head>
        <!--[if IE]><![endif]-->
        <meta http-equiv="Content-Type" content="text/html;charset=UTF-8" />
        <title> </title>

        <!-- Blueprint -->
        <link rel="stylesheet" type="text/css" href="http://typographisme.net/post/css/bp.css" media="all" />
        <!--[if lt IE 8]>
        <link rel="stylesheet" type="text/css" href="http://typographisme.net/post/css/ie.css" media="all" />
        <![endif]-->                                                              

        <!-- #grid --><!-- à supprimer en production -->
        <link rel="stylesheet" type="text/css" href="http://typographisme.net/post/css/hashgrid.css" media="all" />            
    
    </head>
    <!--[if gte IE 8]><body class="ie ie8">    <![endif]-->
    <!--[if IE 7]>    <body class="ie ie7">    <![endif]-->
    <!--[if IE 6]>    <body class="ie ie6">    <![endif]-->
    <!--[if !IE]>-->  <body class="not-ie"><!--<![endif]-->

        <div class="container">

        </div>

        <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.4/jquery.min.js"></script>

        <!-- #grid --><!-- à supprimer en production -->
        <script type="text/javascript" src="http://typographisme.net/post/js/hashgrid.js"></script>
    </body>
</html>

La feuille de style hashgrid.css correspondante à la grille Blueprint est la suivante. Elle permet d’afficher successivement la grille horizontale, la grille verticale, ou les deux.

#grid
{
    width:950px;
    position:absolute;
    top:0;
    left:50%;
    margin-left:-475px;
}
#grid div.vert
{
    width:9px;
    border:dotted darkturquoise;
    border-width:0 1px;
    margin-right:29px;
    content:' ';
}
#grid div.first-line
{
    margin-left:29px;
}
#grid div.horiz
{
    height:1.5em;
    border-bottom:1px dotted darkturquoise;
    margin-bottom:-1px;
}
#grid #grid-horiz.first-line
{
    margin-left:0;
}
#grid.grid-1 div.horiz
{
    border-color:transparent;
}
#grid.grid-2 div.vert
{
    border-color:transparent;
}

Les plus impatients d’entre vous se réfèreront directement au résultat en ligne.

Remarquez que j’ai modifié légèrement le fichier JavaScript pour y supprimer une espace insécable gênante (en mode CSS désactivées) (lignes 123 et 128) et également passer le nombre de grilles à trois (verticale, horizontale et la combinaison des deux) (ligne 337). Je casse du coup la compatibilité avec Internet Explorer mais je n’ai pas pour habitude de caler ma grille avec ce navigateur.

Insérer le contenu

Reste à placer le contenu au sein de votre page. Celui-ci vient à l’intérieur du conteneur justement nommé .container. On réalise le colonnage sans difficulté : la grille verticale proposée est robuste.

Ce n’est pas le cas de la grille horizontale qui va nécessiter plus d’attention. Quelques éléments du contenu avec une hauteur fixe exprimée en pixels venant perturber notre mise en page. Et nous l’avons vu : tout ce qui est vertical devrait (en théorie) être exprimé en em.

Heureusement il existe des astuces.

Contourner le problème des images

Forcer la hauteur de l’image en em semble évidement à proscrire, c’est non seulement une mauvaise pratique mais cela va surtout la déformer. Fort heureusement, il est facile de placer un conteneur supplémentaire autour de l’image et de lui donner à son tour une taille en em.

Pour exemple, l’image contenue dans le pied de page sera codée ainsi :

<p style="height:3em;">
    <a href="http://validator.w3.org/check?uri=referer">
        <img src="http://typographisme.net/post/img/valid.png" alt="Valid XHTML 1.0" height="31" width="88" class="top" />
    </a>
</p>

31 pixels n’étant pas un multiple de 18, je prend le multiple immédiatement supérieur.

36 / 18  = 2
 2 * 1.5 = 3

Pour éviter toute marge sur vos images, n’oubliez pas également de forcer leur affichage en bloc si nécessaire.

Cette technique ne s’applique évidemment pas aux images flottées dans le corps de texte.

Détail intéressant : l’alignement des images bien que parfaitement calé sur la grille n’est en fait pas correct, comme l’explique Anne-Sophie. Il est toutefois possible d’obtenir un effet similaire (au niveau de zoom par défaut) en bidouillant un peu… Je ne m’attarde pas, le résultat est aléatoire. Analysez si besoin le résultat en ligne proposé en fin d’article.

Contourner le problème des tableaux

C’est cette même parade qui sera bien souvent la plus pratique à mettre en place pour les tableaux de données (et tout les autres cas récalcitrants). Calculer la taille d’une cellule de tableau sur laquelle s’appliquent bordures (fusionnées ou non aux cellules adjacentes) et marges internes est un véritable casse-tête.

Il est plus simple (là encore) de placer un conteneur autour de votre tableau et de lui fixer une hauteur, pourvu qu’elle soit exprimée en em et calculée pour tomber sur la grille.

Prenez garde néanmoins : en fonction de votre contenu, il sera peut-être plus préférable de « casser » la grille plutôt que de limiter la hauteur d’un conteneur. À vous de peser le pour et le contre en fonction de votre contexte. N’oubliez pas le min-height (et son équivalent pour IE 6) qui fait des miracles !

Contourner le problème des bordures

Notre page d’exemple comporte quelques <hr> qui sont rendus par une bordure haute d’un pixel. Il est assez rare de travailler avec cette balise mais elle fera un exemple révélateur du problème.

Ce simple pixel peut venir perturber notre beau rythme vertical (d’autant plus si il est répété à plusieurs endroits de la page). Il faut donc y trouver une solution et heureusement plusieurs techniques sont possibles.

Tout calculer en em

Une ligne faisant 18 pixels pour 1.5 em, 1 pixel fait donc 0.08333em. En y ajoutant la ou les marges nécessaires pour compenser, on peut aisément retomber sur la grille.

1.5 / 18     = 0.8333
1.5 - 0.8333 = 1.4166

hr
{
    border:none;
    background-color:#DDD;
    color:#DDD;

    height:0.08333em;
    margin:0 0 1.4166em;
}

Seul inconvénient : au zoom, cette bordure de 1 pixel pourra prendre de l’épaisseur, ce qui peut s’avérer disgracieux.

Ajouter une marge négative

Plus pratique, la marge négative va nous permettre de rétablir l’alignement sur la grille sans pour autant nous empêcher de travailler en pixels.

Ainsi :

hr
{
    border:none;
    background-color:#DDD;
    color:#DDD;

    height:1px;
    margin:-1px 0 1.5em;
}

Il est même possible (voire conseillé) de replacer ensuite la bordure exactement où elle aurait dû apparaître en la décalant visuellement :

hr
{
    border:none;
    background-color:#DDD;
    color:#DDD;

    height:1px;
    margin:-1px 0 1.5em;

    position:relative;
    top:1px;
}

J’utilise personnellement extrêmement souvent cette technique et je vous la conseille.

Jouer avec l’interlignage

Autre astuce, qui n’est pas très pertinente avec le <hr> de l’exemple précédent, mais qui prend plus de sens lorsqu’il s’agit de faire tenir sur la grille un champ de formulaire.

En effet, c’est un véritable challenge de devoir styler les champs de formulaire : en fonction du navigateur une marge interne plus ou moins incompressible s’ajoute à vos calculs et vient les fausser.

La solution que je mets en place ressemble alors à ça :

<p style="line-height:3em">
    <label for="text">Texte</label>
    <input type="text" id="text" name="text" />
</p>

Je m’assure ainsi de centrer verticalement mon champ dans son conteneur et d’y aligner correctement les textes. C’est facile et fonctionnel.

Blueprint inclut une technique similaire dans sa partie destinée aux formulaires… Mais encore une fois je ne trouve pas cette partie correctement finalisée, je préfère donc habituellement la contourner.

Ces quelques astuces mises en place, nous obtenons finalement un modèle fonctionnel qui répond à nos attentes. Je vous laisse le tester vous-même avec Firebug, #grid et la fonction zoom de votre navigateur pour l’éprouver.

Et j’espère bien sûr que vous mettrez vous aussi tout ça en pratique bientôt !

Macro-typographie sur le Web – Quelques outils

Vincent — Tue, 14 Dec 2010 11:07:00 +0100

Anne-Sophie présentait en octobre dernier à Paris Web une conférence sur la macro-typographie. Elle y abordait les problématiques des mises en page sur le Web et plus particulièrement de l’utilisation des grilles. Vous pouvez d’ailleurs enfin (re)visionner sa conférence si vous le souhaitez sur le site de Paris Web.

Bien que les solutions pour les mettre en place ne soient pas nouvelles, je constate qu’elles ne sont pas pour autant adoptées facilement. En partageant mon expérience pratique sur le sujet dans ce billet, j’espère faciliter leur adoption.

Le framework CSS Blueprint a été le premier à me taper dans l’œil et je l’avais donc expérimenté sur des projets personnels. C’est aussi celui qui est utilisé par mes collègues designers, ce qui m’a permis de le découvrir plus largement au jour le jour. C’est donc sur celui-ci que j’appuierai ma démonstration. Notez cependant qu’il s’agit d’un simple choix technique et que ce n’est pas ce qui importera le plus. Adaptez mon discours à vos outils si le besoin s’en fait sentir, pourvu que vous utilisiez une grille ou que le sujet retienne votre attention !

L’objectif à atteindre sera simple et ressemblera à ce qui est présenté sur la vidéo ci-dessus, à savoir :

une mise en page sur plusieurs colonnes ;
un contenu composé de titres, sous-titres, paragraphes, images ;
le tout aligné sur deux grilles : une verticale et une horizontale ;
le tout s’adaptant automatiquement à la taille du texte choisi par l’internaute (les grilles s’adapteront elles-aussi).

Blueprint

Blueprint est proposé au téléchargement sous forme d’une archive contenant une série de fichiers CSS. Publiée en version 1.0 depuis fin septembre, la bibliothèque a été élaborée en plus de deux ans, signe du sérieux travail accompli. Elle n’est pas exempte de défauts pour autant mais nous en reparlerons.

La bibliothèque est disponible sous licence MIT et promet une compatibilité complète avec les navigateurs du marché : elle se veut donc facilement utilisable et robuste.

Une fois l’archive décompressée, nous découvrons outre les habituels fichiers textes explicatifs, plusieurs répertoires :

blueprint qui contient les fichiers utiles de travail (dans leurs versions normales et compressées) ;
templates qui contient un gabarit destiné à Photoshop (avec fonds semi-transparents et règles) ;
lib qui contient des scripts Ruby permettant de modifier et de compresser automatiquement la bibliothèque (ne faisant pas de Ruby, je n’ai jamais eu la curiosité de fouiller plus avant ce répertoire) ;
test qui propose des exemples simples de pages mise en forme à l’aide de Blueprint.

On trouve également dans le répertoire blueprint un sous-répertoire nommé plugins qui comme son nom l’indique, contient des extensions qui permettent à Blueprint de réaliser encore plus de choses. Ne trouvant pas ses plugins aboutis, je ne les utilise pas et n’en parlerai donc pas.

La grille verticale

La grille verticale proposée par défaut avec Blueprint se compose de 24 colonnes d’une largeur de 30 pixels séparées entre elles par des gouttières de 10 pixels. Aucune gouttière avant la première colonne, ni après la dernière colonne : cela n’aurait aucune utilité. La largeur totale de la page fait donc 950 pixels.

 24 * 30  = 720
 23 * 10  = 230

720 + 230 = 950

Par défaut il est donc proposé un grand nombre de colonnes mais il est bien sûr conseillé de composer votre grille sur un nombre plus restreint. Ça tombe plutôt bien car 24 est facilement divisible par 2, 3, 4, 6, 8 et 12 : ce qui permet de composer aisément des grilles avec des colonnes plus larges.

6 colonnes par exemple :

 24 / 6   = 4

  4 * 30  = 120
  3 * 10  = 30
120 + 30  = 150

  6 * 150 = 900
  5 * 10  = 50
900 + 50  = 950

L’alignement sur les colonnes se fait simplement à l’aide des classes .span-X, append-X, prepend-X, push-X, pull-X… Le nombre X indiquant le nombre de colonnes souhaité. Ces classes sont complétées par l’habituel .clearfix, .clear mais aussi par les classes .last .border ou .colborder. C’est ainsi très pratique de construire un layout extrêmement rapidement. Cette tâche fastidieuse de mise en place des colonnes est donc totalement prise en charge par la bibliothèque.

Si cette syntaxe ne vous est pas familière je ne saurais vous conseiller de parcourir le code source d’un des exemples proposés sur le site de Blueprint. Accompagné si besoin de la traduction du tutoriel de démarrage rapide officiel.

Si toutefois cette grille ne vous convenait pas, sachez que vous pouvez sans souci vous en confectionner une autre, la philosophie reste la même, seules les valeurs dans la CSS changeront.

La grille horizontale

Chose plus rare (la plus connue des bibliothèque CSS ne le propose pas par exemple) mais aussi extrêmement intéressante : le framework propose une grille horizontale. Cette dernière se compose d’une succession de lignes ayant pour hauteur 18 pixels. Cette valeur de 18 pixels est en fait calculée, puisque exprimée en réalité dans une unité relative et fixée à 1.5em.

Les textes par défaut étant fixés à 12 pixels (1em), cela respecte scrupuleusement les spécifications d’accessibilité (WCAG 2) qui indiquent que l’interlignage des paragraphes doit être d’une valeur d’au moins 1.5 fois la taille du texte.

 1em * 1.5 = 1.5em
12px * 1.5 = 18px

Pour changer la taille par défaut des textes (pour un titre de niveau trois à 15 pixels par exemple) on complète sa feuille de style ainsi :

h3.exemple {
    font-size:1.25em;
    line-height:1.2;
    margin-bottom:1.2em;
}

Ce résultat étant obtenu par une simple règle de trois.

15 / 12 = 1.25
18 / 15 = 1.2

Notez que la marge basse est également redéfinie, l’initiale fixée à 1.5em n’étant plus juste pour suivre convenablement la grille.

On se souviendra plus simplement que :

Taille de texte en em = taille du texte voulue en pixels divisé par taille initiale du texte en pixels.
Interlignage et marges = interlignage initial en pixels divisé par taille du texte voulue en pixels.

Là encore, si vous souhaitez changer la valeur par défaut de la grille horizontale c’est tout à fait possible. Il faut seulement (manuellement ou via un générateur) recalculer l’ensemble des marges verticales de la bibliothèque.

Pourquoi est-ce intéressant de travailler avec des unités relatives ?

Sans doute pas pour le plaisir de compliquer les choses, n’est-ce pas ?

C’est en fait une question complexe et je crois que personne n’a de réponse aboutie et argumentée à ce sujet : la plus grande confusion règne entre le zoom page, le zoom texte ainsi que les polices exprimées en unités fixes ou relatives.

Ne pas confondre le zoom page et le zoom texte est primordial. Ce sont deux outils différents, et l’un ne remplace pas l’autre.

Le zoom page

Cet outil va agir comme le ferait une loupe : tout le contenu de la page est zoomé sans distinction. Cela pouvant obliger à panoter afin d’obtenir une vision globale de la page. En gros, ce n’est ni plus ni moins que le bon vieil outil loupe, mais intégré au navigateur : rien de nouveau donc, si ce n’est de l’avoir toujours sous la main.

Notez en passant que cet outil n’est pas proposé sous IE 6.

Le zoom texte

Le zoom texte, quand à lui ne grossira que les éléments textuels ; si votre page est bien construite, elle devrait donc pouvoir s’étendre en hauteur sans pour autant se dégrader visuellement.

Autre point important : faut-il préférer les unités fixes ou les unités relatives ?

Bien que travailler avec des unités fixes ne pose pas de problème, sachez d’abord que sous Internet Explorer cela empêchera toute modification de la taille du texte par l’utilisateur. Préférant toujours laisser le choix à l’utilisateur (le pauvre, il est déjà sous IE !), je trouve intéressant de ne pas le brider d’avantage.

Enfin, autre point bloquant : en mode zoom texte (comme nous l’avons vu plus haut), les marges exprimées en pixels ne s’adaptent pas à la taille du texte. Elles restent donc fixées en hauteur. Cela empêche directement de composer avec tout rythme vertical. Pouvoir aligner horizontalement les titres de deux colonnes quelle que soit la taille du texte ne sera possible qu’avec une grille horizontale bien construite.

Par ailleurs, les spécifications et les bonnes pratiques viennent appuyer cette démonstration :

Mais quoi qu’il en soit, c’est le choix qui a été fait avec Blueprint.

Retenez que les tailles concernant la largeur doivent être exprimées en pixels et que celles concernant la hauteur doivent être exprimées en em.

D’autres bibliothèques n’ont pas fait ce choix, n’hésitez pas les étudier (voire à les adopter) si vous n’êtes pas convaincu par cette démonstration.

Pourquoi faut-il être méticuleux dans les calculs ?

Travailler avec des valeurs relatives (de surcroît arrondies ensuite en pixels) doit se faire avec beaucoup de méthode. Vous savez tous en effet que les navigateurs ont des techniques parfois bien différentes pour arrondir vos résultats. Ce qui peut se révéler rapidement gênant et casser votre grille horizontale sans que vous ne vous en rendiez compte.

Aussi trois conseils :

appuyez toujours votre démarche sur un raisonnement mathématique (une simple règle de trois en général, pas de panique), le pifomètre ne marche pas ;
arrondissez vos résultats au moins à quatre chiffres après la virgule pour vous assurer un calcul suffisamment précis ;
le pixel est une unité indivisible, vos résultats doivent donc tomber (le plus souvent) sur des chiffres ronds lorsqu’ils sont exprimés en pixels.

Pour les personnes intéressées plus particulièrement par la grille horizontale, je vous recommande chaudement cet outil.

Revers de la médaille

Cette facilité de construction a évidemment un prix. C’est une évidence mais il faut avant tout que le design de votre page soit initialement prévu pour la grille. Aussi étonnant que cela puisse paraître de nombreux designers ne l’entendent pas de cette oreille et crient à la contrainte lorsqu’il s’agit de s’y conformer. De nombreux ouvrages traitant du sujet, de nombreux exemples prouvant le contraire, je ne m’attarderai donc pas sur ce point. Je conseille aux plus irréductibles de visionner la conférence d’Anne-Sophie qui démontre brillamment l’utilité des grilles.

Autre reproche souvent évoqué : l’ajout de classes non-sémantiques sur le contenu html. Ce point est tout à fait pertinent.

On se retrouve en effet à placer petit à petit un grand nombre de données concernant la présentation au sein du HTML. Ce qui peut être problématique à long terme en cas d’évolution de site. Il faudra alors non seulement retoucher aux fichiers CSS, mais aussi au HTML. Dans la pratique, j’avoue sans honte que c’est extrêmement rare comme cas de figure et en aucun cas problématique. Aussi, je passe bien volontiers sur ce défaut au regard des avantages apportés par ailleurs. Que celui qui n’a jamais placé de classe .clearfix dans son HTML me jette le premier commentaire…

Plus grave cette fois, ces classes empêchent toute portabilité de la structure. À moins de surcharger allègrement le framework, il sera difficile d’adapter une page Web à son équivalent mobile… La magie de la feuille de style adaptée au média en prend un sacré coup. Attention donc à ce point : d’autant que c’est de plus en plus d’actualité.

De nouvelles bibliothèques promettent de s’affranchir du sujet. Elles choisissent par contre un parti-pris plus radical en ne proposant un fonctionnement sous IE qu’à l’aide de JavaScript. C’est osé… Mais c’est une décision qui vous revient au final.

Notez enfin que Blueprint ne pèse pas moins de 12 Ko, ce qui n’est pas négligeable. Chargez donc la bibliothèque à bon escient et utilisez-en les ressources au maximum. Une fois encore si besoin est, les alternatives existent…

#grid

En parallèle de Blueprint, j’ai découvert #grid, un outil très pratique qui permet de superposer la grille au travail en cours. #grid est disponible (actuellement en version 5) au téléchargement sous forme d’une archive qui ne contient qu’un fichier JS et un exemple de travail.

Pour fonctionner il faudra lui adjoindre quelques règles CSS.

À l’utilisation, il suffira de donner le focus à la page puis d’appuyer ou de combiner les bonnes touches du clavier :

F permet jouer avec le z-index de la grille ;
G permet d’afficher la grille ;
H permet de conserver l’état courant (à combiner donc avec la touche G) ;
J permet de basculer d’une grille à l’autre.

Détails appréciables :

l’état courant est automatiquement sauvegardé via un cookie ;
la grille ne viendra pas interférer avec Firebug, ce sont bien vos éléments de page qui seront sélectionnés au survol ;
l’outil ne réclame aucune image supplémentaire pour fonctionner, tout est géré par CSS ;
la grille horizontale peut être configurée à l’aide d’unités relatives ! Elle s’adaptera donc à la taille de votre texte.

Firebug

L’extension de Firefox Firebug (passée récemment en version 1.6) est bien connue des développeurs Web front-office. Elle viendra compléter notre petit panel d’outils et sera d’une grande aide pour s’assurer de la bonne composition de la page sur la grille.

Après avoir sélectionné un élément HTML en parcourant l’arbre du document ou en survolant la page, son inspection fera apparaître :

les valeurs verticales exprimées en em dans l’onglet Style ;
les valeurs verticales calculées par le navigateur exprimées en pixels dans l’onglet Apparence.

Et aussi :

les tailles de textes et d’interlignages exprimées en em dans l’onglet Style ;
les tailles de textes et d’interlignages calculées par le navigateur exprimées en pixels dans l’onglet Calculé.

On s’assure ainsi très facilement que ses valeurs correspondent à la grille employée.

Autre technique plus empirique mais tout aussi pratique : la mise en surbrillance des éléments survolés combinée à l’affichage de la grille à l’aide de #grid.

Bref, le compagnon idéal une fois de plus ; je ne m’attarde pas.

Mise en pratique

Il ne nous reste plus qu’à mettre tout ça en musique. Ce sera l’objet d’un second article dans lequel nous détaillerons étape par étape la construction de la page. Vous le verrez, il reste encore quelques astuces à mettre en place.

Web Font Specimen traduit et adapté en français

Vincent — Mon, 08 Nov 2010 10:47:00 +0100

Une page pour tester en profondeur le rendu de vos polices Web à l’écran : ce serait chouette, non ? C’est exactement ce que propose le Web Font Specimen. Et cet outil est aujourd’hui disponible en français, documentation comprise.

Je me suis intéressé au Web Font Specimen suite à la lecture de l’une des traductions réalisées sur (l’excellent) Pompage : De la vraie typographie pour le Web.

Tim Brown, l’auteur de l’article original (publié sur A List Apart) y explique en détail pourquoi il est nécessaire de tester le rendu des polices à l’écran sur différents navigateurs avant de faire ses choix typographiques.

Il propose pour cela une page Web pratique et facile à configurer, qu’il convient de s’approprier pour réaliser ensuite ses propres tests.

Ayant trouvé son projet intéressant, j’ai décidé de pousser un peu plus loin le travail de traduction en réalisant celle du site Web hébergeant le spécimen lui-même.

J’en ai également profité pour modifier légèrement le spécimen de test en l’adaptant à nos contraintes francophones. On retrouve ainsi dans la page des pangrammes francisés ainsi que les lettres accentuées, quelques ligatures et la plupart des signes de ponctuations utilisés dans nos contrées.

Le document n’est pas parfait (les espaces fines se comportent mal avec le navigateur Opera par exemple), mais il est tout à fait conseillé de se l’approprier et de l’adapter à ses besoins. La licence sous laquelle il est publié le permet ; et l’auteur l’encourage.

J’espère avec cette traduction faciliter le difficile travail des designers Web qui, tout heureux de pouvoir personnaliser enfin les polices sur le Web, écopent également de quelques nouvelles contraintes…

Découvrez (et utilisez !) le Web Font Specimen, en français.

Les formats de polices typographiques pour le Web

Jeremie — Wed, 03 Nov 2010 12:20:00 +0100

Comme les images, les vidéos ou le son, les polices typographiques sur un ordinateur ne sont jamais que des fichiers ayant un format spécifique. Seulement voila, des formats de fichiers pour les polices typographiques il y en a une ribambelle. Tous ont des avantages et parfois des inconvénients. Je vous propose de nous pencher plus en détail sur ceux qui sont, aujourd’hui, exploitables dans un contexte Web, c’est à dire au sein des déclarations @font-face.

Commençons par une petite analyse macroscopique

Un fichier de police typographique contient toutes les informations requises pour qu’un ordinateur puisse afficher les caractères correspondant. Cela comprend en général :

L’ensemble des tracés vectoriels de chacun des caractères (il existe également des formats de polices typographiques Bitmap, mais leur usage est ultra spécifique et jamais sur le Web)
Des meta-données diverses et variées
Des informations supplémentaires pour gérer le lissage de la police à l’écran et de manière générale le changement d’échelle des caractères vectoriels (on utilise souvent l’anglicisme « Hinting »)
Des informations supplémentaires pour gérer les approches entre caractères (on utilise souvent l’anglicisme « Kerning »)

Outre le fait que tous les formats de polices typographiques ne sont pas égaux face à ces 4 points, chacun répond à des problématiques parfois différentes et il peut être difficile de s’y retrouver. Passons donc au vif du sujet

Le format de police SVG (.svg)

Ce format date de la fin des années 90 et fait partie de la norme du format d’image vectoriel SVG. À cette époque, les concepteurs de SVG cherchent un moyen pour embarquer les polices typographiques des documents SVG directement au sein de ces documents afin d’assurer la cohérence du rendu graphique quel que soit le terminal utilisé. Ils décident finalement de créer leur propre format qui, grossièrement, consiste à relier n’importe quel tracé SVG à un caractère unicode.

Ce format offre une souplesse de création sans précédent reposant sur toute la puissance de SVG. Il est ainsi possible d’utiliser tout les outils de SVG comme les motifs, les dégradés, les filtres, les animations, etc. Il est même possible d’imaginer des polices typographiques exploitant la vidéo, le son ou des comportements gérés via des scripts Javascript.

Cette souplesse créative est compensée par un défaut que certains qualifient de majeur aujourd’hui mais qui à l’époque ne paraissait pas si important. En effet, le format SVG ne dispose d’aucun mécanisme lui permettant d’embarquer des informations de hinting. Cela peut se faire sentir sur les écrans de faible résolution ou dans les petits corps de texte.

Enfin, le format SVG étant un format XML, les fichiers peuvent vite devenir assez lourds. Pour palier à ce problème, il existe une variante compressée de ce format et qui porte l’extension .svgz. Elle reste cependant peu ou pas supportée par les navigateurs. En outre, si votre serveur sait gérer la compression des requêtes HTTP, cet artifice n’est pas très utile.

Les formats de police TrueType et OpenType (.ttf, .otf)

TrueType est sans doute le format le plus ancien utilisé sur le Web. Il a été créé à la fin des année 80 par Apple en réponse au format PostScript Type 1 de Adobe. Outre un changement dans la façon de définir les points de contrôle de chaque lettre, la principal caractéristique de ce format tiens à l’apparition du hinting. En effet, grâce à TrueType, les polices typographiques deviennent « intelligentes » et donnent directement aux logiciels tout un jeux d’instructions permettant l’optimisation de leur rendu, en particulier pour les petits corps de caractères.

Le format OpenType est une évolution du format TrueType datant de la fin des années 90 et réalisé sous l’égide de Adobe et Microsoft. En fait c’est une sur-couche qui utilise indifféremment la description des glyphes de TrueType ou de PostScript Type 1. Il normalise également l’encodage des caractères en se reposant sur unicode et rajoute la possibilité de gérer des DRM. Ce format offrant plus de souplesse à la chaîne graphique traditionnelle tout en permettant aux fonderies de contrôler leurs créations, son adoption fut massive et c’est à présent le format dominant sur le marché.

En fait, désormais, la plupart des fichiers de polices typographiques ayant l’extension .ttf sont en réalité des fichiers OpenType qui utilisent la description des glyphes TrueType. À l’inverse, les fichiers ayant l’extension .otf sont le plus souvent des fichiers utilisant la description des glyphes du format PostScript Type 1. Les différences entre les deux sont extrêmement subtiles et généralement peu ou pas perceptibles hors de cas particuliers spécifiques à chaque police.

Ces deux formats sont particulièrement riches et contiennent généralement énormément d’informations destinées à optimiser le rendu des polices. De fait, ce sont des formats idéaux pour la chaîne graphique traditionnelle mais qui conviendront assez difficilement aux usages Web. D’une part, dans la mesure où ces formats de fichier ne sont pas (ou peu) compressés et contiennent généralement des jeux de caractères complets, leur poids est prohibitif (les fichiers font facilement plusieurs centaines de Ko). D’autre part, les fondeurs traditionnels n’autorisent généralement pas la duplication des fichiers de polices ni la créations de jeux de caractères réduits, il est donc légalement difficile d’utiliser des polices typographiques issues des bibliothèques des grandes fonderies (Adobe, ITC, Linotype, etc.).

Le format de police Embedded OpenType (.eot)

Afin de résoudre la plupart des problèmes que peut poser OpenType dans un cadre Web, Microsoft, à la fin des années 90, a proposé un format de fichier allégé pour embarquer les polices typographiques dans Internet Explorer. En particulier, il permet de réduire assez efficacement le poids des fichiers en proposant des sous-ensembles de caractères et en compressant le fichier. L’idée est séduisante mais souffre de deux défauts. Premièrement, seul Internet Explorer supporte ce format de fichier (son concurrent de l’époque, Netscape Navigator, ayant fait le choix d’un autre format, disparu depuis). Deuxièmement, ce format arrive (trop ?) tôt dans l’histoire du Web et à l’époque, les grandes fonderies sont hésitantes sur la marche à suivre et finalement ne participeront guère à l’effort de promotion de ce format.

Du point de vue des designer Web, ce format souffrait aussi d’un autre problème : il est fermé (ce qui contribue au fait, qu’aujourd’hui encore, il n’y a toujours aucun autre navigateur qui le supporte), non interopérable et les outils disponibles pour créer des fichiers à ce format n’existaient que chez Microsoft. Ainsi, entre un manque d’information, des outils fermés et une époque où le haut débit n’était pas encore là, ce format est resté longtemps inconnu et sous-utilisé malgré ses qualités.

Le format de police WOFF (.woff)

Petit nouveau dans l’univers des formats de fichier pour les polices typographiques, le format WOFF date de 2008 et est une proposition de Mozilla pour fournir un format de fichier spécialement pensé pour le Web. Pour faire simple, il reprend toutes les bonnes idées du format EOT (sous-ensemble de caractères et compression du fichier) tout en en supprimant ses défauts. En particulier, ce format est ouvert et fait l’objet d’un processus de normalisation au sein du W3C. Il a donc vocation à devenir le format de référence pour les polices typographiques sur Internet. D’ailleurs, tous les grands fabricants de navigateur sont en train de franchir le pas et commencent à implémenter son support.

De manière un peu surprenante, les fonderies font un bon accueil à ce format de fichier dans lequel elles voient un bon moyen de proposer leur catalogue pour des usages Web (d’une manière bien plus clairement distincte que ce que pouvait proposer le format EOT). Ceci dit, ce format de fichier ne propose pas spécialement de système de DRM et donc rien n’empêche techniquement l’usage de ce format de fichier ailleurs que sur le Web ou dupliqué d’un site à l’autre. Ceci étant, les fonderies ont revu leur position depuis 10 ans et font tout pour négocier au mieux le virage du numérique. Dans cette optique, elles suivent et soutiennent activement les démarches qui visent à proposer une utilisation légaliste des polices typographiques sur le Web, d’où le support de ce format et le soutien donné aux nouvelles formes de distribution (l’exemple de TypeKit est emblématique de cette politique).

Support navigateur

Tous ces formats de fichiers peuvent être utilisés par l’un ou l’autre de nos navigateurs préférés, mais qui supporte exactement quoi ?

	6-8	9	3.5	3.6	4-6	7	3.1	iOS	10

SVG	non	non	non	non	non	non	oui	oui	oui
TTF	non	non	oui	oui	oui	oui	oui	non	oui
OTF	non	non	oui	oui	oui	oui	oui	non	oui
EOT	oui	oui	non	non	non	non	non	non	non
WOFF	non	oui	non	oui	non	oui	non	non	non

Vos avis sur @font-face

Anne-So — Tue, 26 Oct 2010 20:05:00 +0200

Le billet précédent sur @font-face a suscité de réactions nombreuses, vives et intéressantes, et je pense qu’il est utile d’en faire une synthèse, pour éclaircir les points de vue, voire dissiper quelques malentendus, et surtout compléter et enrichir ce que j’avais écrit et qui n’avait nullement la prétention d’être exhaustif, vous vous en doutez bien.

Quelques malentendus, donc…

La formulation était peut-être un peu lapidaire, mais (Pas Pirate, si tu m’entends) je n’ai nullement voulu décrédibiliser le libre ni sous-entendre que les utilisateurs de dafont.com étaient des pirates en puissance. Je crois au logiciel libre, et je suis très sérieuse en disant cela. Il y a notamment un très beau projet en matière de typographie, la police Gentium, dont j’espère que nous aurons l’occasion de parler. Derrière « les utilisateurs de dafont.com », je voyais surtout une masse d’internautes qui sont plus en quête de polices fantaisie que de rigueur typographique (oui, il y a des fontes de qualité sur dafont, mais elles sont rares) et qui apprécient justement qu’elles soient gratuites et librement utilisables. Dans cette masse d’internautes, il y a des libristes effectivement, mais aussi une masse de gens qui n’ont pas envie de se soucier des licences, et dont c’est parfaitement le droit.

Quant à l’ancienneté d’@font-face, c’est effectivement une vieille propriété, mais son usage est devenu vraiment possible à partir de l’année dernière, d’où la datación de la revolución.

@font-face sous Windows

La conclusion : ce n’est pas du tout au point visiblement. La faute au format EOT qui fait des pâtés et à l’anti-aliasing du système d’exploitation. STPo a notamment pointé du doigts des problèmes de crénage (kerning, letter-spacing, approche, appelez ça comme vous voulez). Auré choisit de se rabattre sur les polices websafe par sécurité et souci d’homogénéité d’un navigateur à l’autre. Il y aurait donc plusieurs solutions à cela : utiliser Cufon comme le suggère Kaelig (bien que cela puisse être délicat du point de vue de la licence – encore), patienter gentiment que la technologie progresse (Typekit se pencherait sur le problème), ou faire de l’espionnage à coup de Javascript pour servir autre chose à vos visiteurs sous Windows (solution qu’on peut légitimement qualifier de sale).

Licences et piratage

Plusieurs problèmes ont été soulevés, d’autant plus pertinents qu’il s’agit souvent de retours d’expérience. Ainsi les designers et les agences, loin d’être vertueux, ne se soucient pas toujours de payer les licences requises. À cela je réponds : c’est très mal. Quand on est pro, on peut se faire contrôler. Faites un peu attention. Il a également été signalé que le modèle Typekit, s’il est attractif et pratique, n’est pas idéal dans la mesure où il faut renouveler sa licence tous les ans. Olivier a toutefois rappelé un point intéressant : les chartes graphiques incluent des polices, et s’il devient possible pour une entreprise d’utiliser les polices de sa charte sur son site Web, elle a tout intérêt à se préoccuper des droits sur le web comme elle le fait pour le print.

Concernant les craintes que peuvent avoir les fonderies, les avis sont partagés : certains considèrent qu’effectivement le piratage est déjà facile et pratiqué, donc la différence est faible. Pour d’autres, @font-face peut être une menace. Je penche toujours pour la première option, mais je vais répondre : le temps nous le dira ma bonne dame.

Et pour enfoncer le clou, il existe effectivement des polices libres de qualité, j’ai cité Gentium plus haut mais quand j’étais sous Linux j’aimais bien la famille des Luxi, certaines Bitstream Vera, et j’en passe. Mais l’intérêt de l’utilisation de ces polices avec @font-face reste à discuter dans la mesure où elles ont plus vocation à être « standard » et lisibles qu’originales.

C’est scandaleux, les espaces ne sont pas insécables devant les ponctuations doubles !

Maintenant, si. Merci à Franck et à son beau plugin Dotclear (non rétroactif) : Typo.

Un avis sur @font-face

Anne-So — Fri, 22 Oct 2010 11:07:00 +0200

La bonne représentation de la typographie à Paris Web a été l’occasion d’aborder brièvement @font-face, la révolution de 2009 qui devait nous délivrer des polices websafe autant que du sIFR et des scripts PHP douteux, employés pour rendre du texte dans la police de son choix.

La nouvelle de la prise en charge d’@font-face sur les grands navigateurs actuels ne pouvait que susciter l’enthousiasme, mais une fois les brumes du délire dissipées, il reste un certain nombre de problèmes et de questions qui font que papoter @font-face peut, contre toute attente, virer au pugilat. Cet article étant un poil long, la maison fournit gracieusement le sommaire :

A-t-on vraiment besoin de @font-face ?

Avant même de m’interroger sur son utilisation, j’ai commencé, en bonne réactionnaire, à me demander si @font-face était vraiment nécessaire. La question peut paraître un peu bizarre dans la mesure où ça fait des années qu’on se cogne les mêmes font-stacks et qu’Arial, Verdana et Times nous sortent par les yeux. Pourtant, certaines polices websafe (Verdana et Georgia) ont été dessinées spécifiquement pour l’écran, elles sont particulièrement lisibles grâce à leur gros oeil, et elles sont fort bien rendues. En plus, Georgia est très esthétique, c’est une vraie réussite sur le plan du dessin. Pas besoin d’avoir @font-face pour composer des textes lisibles et agréables : on avait déjà les outils optimisés pour.

D’autre part, je me fais souvent la réflexion qu’à l’époque du plomb, les imprimeurs n’avaient pas 1500 typos dans leurs ateliers. Imaginez : une casse par corps et par variante. Ça prend de la place. Les typographes s’appuyaient en général sur une dizaine de typos qui répondaient à 99% de la demande. Les polices Websafe ne font que reproduire ces conditions, et comme toutes les contraintes en matière de design, elles poussent à faire preuve d’originalité dans la composition de la page. En tombant sur des designs inattendus, des usages originaux, j’ai vraiment redécouvert le Times et le Georgia que je ne voyais plus.

Donc dans l’absolu je dirais qu’@font-face n’est pas indispensable. Par contre, c’est un vrai bonheur, une liberté nouvelle – et un gage d’accessibilité, dans la mesure où il n’est plus nécessaire de passer par l’image pour afficher du texte dans une typo non websafe. Sur le plan du design, ça fait environ la même chose que d’ouvrir la fenêtre en grand au retour des beaux jours. Pourtant, quelques voix s’élèvent régulièrement contre @font-face, principalement pour deux raisons : l’inégalité de la prise en charge et la crainte du piratage des polices mises à disposition sur le serveur.

Du côté du support et de l’implémentation

Effectivement, côté prise en charge (et donc implémentation), c’est pas vraiment le temps des cerises. Chaque navigateur a son format préféré, si bien que pour utiliser @font-face vous devez fournir et déclarer le fichier de police en trois formats (TTF, EOT et SVG) pour assurer un minimum d’interopérabilité. Si en plus vous vous souvenez que vous devez prévoir un fichier pour chaque variante ou graisse que vous comptez utiliser, vous pouvez rapidement arriver à 3 fichiers x 4 variantes (romain, italique, gras, italique gras (enfin celui-là vous pouvez vraiment vous en passer – si si, j’insiste)), soit 12 fichiers, plein de lignes de CSS, et on n’a pas encore intégré le facteur poids.

L’espace de stockage n’est pas vraiment le problème, c’est plutôt la bande passante et le débit des utilisateurs (et puis c’est un peu fastidieux tout ça, il faut le reconnaître). Je vous rappelle tout de même, au passage, que le visiteur ne charge que les fichiers dont son navigateur a besoin. On peut diminuer cette charge de plusieurs façons. D’abord en limitant le nombre de polices utilisées, ce qui est de toutes façons préférable d’un point de vue strictement esthétique, mais aussi en créant des subsets, c’est à dire en ne conservant, dans les fichiers de police, que les caractères vraiment utiles. Vous pouvez le faire vous-même avec une appli de création de fontes, mais vous pouvez aussi demander à un service Web de le faire pour vous, ce qui prend 97% de temps en moins d’après une étude. Je pense notamment à FontSquirrel : vous lui donnez votre police, vous choisissez votre subset selon des critères aussi simples ou compliqués que vous voulez, et il vous donne un gros zip contenant votre subset dans tous les formats demandés, accompagné du bout de CSS qui va bien. Formidable.

Faire les choses dans les règles

Naturellement, vous savez bien que vous ne pouvez pas utiliser n’importe quelle police de cette façon. Surtout pas celles que vous avez fauchées à vos copains, parce que sur le Web, ça se voit. A priori, on pense aux polices gratuites qu’on trouve un peu partout. C’est effectivement une bonne idée, surtout si on les choisit bien. Et contrairement à la légende, il y a des polices gratuites très bien réalisées, pour la simple raison que ce sont des fonderies qui les diffusent pour se faire un peu de pub. Profitez-en. Elles sont rares mais faciles à trouver.

Ça c’est la solution Jamendo. Allons faire un tour du côté d’iTunes. Il existe tout un tas de services Web qui s’associent aux fonderies pour proposer des licences Web pour des polices de grande qualité, autant pour le titrage que le texte courant. Les tarifs sont, selon moi, raisonnables. L’avantage de cette solution : le service héberge les polices et les sécurise. Les fonderies font confiance et n’ont pas peur de voir leur marchandise téléchargée impunément. Résultat : vous avez à disposition un choix de plus en plus grand de belles polices, et vous n’avez pas besoin de lire la licence de vos typos dans son intégralité pour savoir si vous êtes dans la légalité.

L’angoisse du vilain pirate tipiak

Les fonderies ont une trouille, qui explique le développement très rapide des services comme Typekit, Webfonts et autres. Que les gens utilisent des polices payantes sur le Web avec @font-face, sans aucune sécurité. En moins de 5 secondes, n’importe quel utilisateur peut récupérer le ttf. Mon avis, c’est que la télévision a trop parlé de la prétendue ruine de l’industrie du disque causée par le téléchargement illégal, et que les fonderies regardent trop la télé. Elles omettent un élément essentiel : la musique, c’est du divertissement. Une police, c’est un outil de travail.

D’abord, mettons-nous d’accord. Le vrai danger, pour les fonderies, est que leurs ventes baissent. Pas que Gaëlle Madec, vétérinaire à Plougastel, ait une police à 300 € sur son ordi sans l’avoir payée. Puisque si Gaëlle Madec est vétérinaire et pas designer, ça ne représente pas un manque à gagner pour la fonderie, dans la mesure où il ne serait jamais venu à l’esprit de Gaëlle Madec de mettre 300 € dans une famille, fût-elle jolie (il y a même fort à parier que Gaëlle Madec ne se doute pas qu’un famille de polices puisse coûter ce prix-là mais passons).

Ensuite – je ne voudrais pas choquer les fonderies, s’il y en a dans l’assistance, qu’elles s’assoient (comment une fonderie peut-elle s’asseoir, je me le demande) – les polices payantes circulent depuis longtemps sur Internet dans l’anarchie la plus totale. Sans vouloir être brutale, trouver un torrent ne prend pas beaucoup plus de temps que d’explorer une CSS pour y trouver une URL. Or, en dépit de cette piraterie, Jean-François Porchez n’a toujours pas été englouti par un calamar géant.

Kraken invoqué par des pirates pour couler une fonderie dans l’Interweb déchaîné.

Et pour revenir au point que je citais précédemment, en faisant un peu de psychologie de comptoir, on se rend compte que le danger est assez mince. Qui est susceptible d’utiliser @font-face avec des polices payantes de fonderies ? Des designers. Qui est obligé d’avoir une licence légale pour sa suite Adobe ? Les designers. Qui peut passer les achats de licences de police en frais professionnels ? Les designers. Qui a des chances d’avoir une vague idée du travail que représente une typo et un minimum de respect pour les dessinateurs de caractères ? Les designers. Qui utilise une version craquée d’Adobe et va redécorer son blog avec @font-face en se fichant complètement des histoires de licence ? Des fans de dafont.com.

Je ne dis pas que @font-face ne va pas, dans une certaine mesure, faciliter la circulation non réglementée de polices payantes à succès. Je ne dis pas non plus que cela n’aura aucun impact sur les ventes des fonderies. Mais je pense que celles-ci ont eu la réaction la plus saine qui soit en optant immédiatement pour des modèles commerciaux comme celui de Typekit. Elles ont réagi très rapidement et ce nouveau modèle de licence a été très bien accueilli par la communauté. Contrairement aux maisons de disque, les fonderies n’ont pas attendu, en proposant tout de suite une offre légale, simple d’utilisation et abordable. La relation fonderie-designer (Web ou print) n’a rien à voir avec celle qu’EMI entretient avec ses clients finaux, et c’est en s’appuyant sur cette base et en la renforçant que les fonderies continueront de prospérer.

Cet article ayant suscité de nombreux commentaires - et nous vous en remercions - il a fait l’objet d’une deuxième partie : Vos avis sur @font-face.

Typographisme - Design Web

De la césure et du Web

Au début était HTML

Puis vint JavaScript

Enfin apparut CSS

Le mot de la fin

Macro-typographie sur le Web – Une grille dynamique

Rappels

Less

Méthodologie

Une grille configurable

Une séparation stricte du contenu et de la présentation

Comment ça marche ?

Simplifier les calculs en em

Des fichiers optimisés

grid.less ?

Les ligatures dans les navigateurs

C’est quoi une ligature ?

Ligatures obligatoires

Ligatures ordinaires

Ligatures esthétiques

Ligatures spécifiques

Comment ça marche techniquement

Les ligatures dépendent de la police de caractère…

…et du navigateur

Caractères et entités XML

SVG text-rendering

CSS3 font-feature-settings

Le pour et le contre

Pourquoi les fontes SVG sont-elles différentes des autres ?

Oubliez le texte courant

Le pouvoir du dessin

Animations, filtres, vidéo… \o/

Inclusion et arbre DOM

Sécurité, accessibilité, bla, bla, bla…

La justification sur le web : usages et précautions

Les contraintes techniques du Web

Un peu d’accessibilité aussi

Ite missa est

Maîtriser le délai d'affichage des fontes

Avantages et inconvénients des deux solutions

Afficher les fontes uniquement après leur chargement

Afficher les fontes de substitution en attendant le chargement

Et c’est quoi le mieux ?

Limiter le clignotement

Bien choisir votre chaîne de polices CSS

Harmoniser les hauteurs d’x

Choisir le comportement que l’on veut.

Conclusion

Bonnes pratiques pour les déclarations @font-face

Petit rappel historique

Déclaration simplifiée

Gestion des formats de fonte

Le cas Internet Explorer

Les alternatives

Conclusion

MAJ du 4 Fevrier 2011

Macro-typographie sur le Web - Mise en pratique

Mise en place du modèle

Insérer le contenu

Contourner le problème des images

Contourner le problème des tableaux

Contourner le problème des bordures

Tout calculer en em

Ajouter une marge négative

Jouer avec l’interlignage

Macro-typographie sur le Web – Quelques outils

Blueprint

La grille verticale

La grille horizontale

Pourquoi est-ce intéressant de travailler avec des unités relatives ?

Le zoom page

Le zoom texte

Pourquoi faut-il être méticuleux dans les calculs ?

Revers de la médaille

#grid

Firebug

Mise en pratique

Web Font Specimen traduit et adapté en français

Les formats de polices typographiques pour le Web

Simplifier les calculs en `em`