Cet article a été réactualisé il y a 3 ans jours. Il n'est pas nécessairement obsolète, mais gardez son ancienneté en tête lors de sa lecture.
Quand il est question d’afficher des pages ou des articles, il est préférable que les lignes de texte ne soient pas trop longues pour qu’elles soient plus facilement lisibles.
Combien de caractères sur une ligne de texte ?
Une ligne de texte, dans une consultation de site web sur écran large, ne devrait pas excéder 80 caractères. Ce n’est pas une règle absolue, mais la moyenne communément admise se situe entre 65 et 80 caractères dans une fonte sans sérif, en comptant à la fois les lettres et les espaces. Ce nombre de caractères dépend de la taille de la police utilisée et de la largeur de son conteneur.
Si le visiteur a la possibilité de zoomer le site dans son navigateur, forcément le nombre de caractères s’affichant par ligne se modifiera. Il peut donc modifier l’apparence du site pour l’adapter à un confort de lecture qui lui est propre. Mais ce n’est pas vraiment le sujet ici. La question est de limiter le nombre de caractères s’affichant par ligne d’emblée pour tous dans une lecture du site sur grand écran, sans modifier le rendu prévu de base.
Cette préconisation, quoique justifiée, n’est pas forcément toujours simple à concilier avec l’apparence qu’on a choisie pour un site.
Comment limiter le nombre de caractères sur une ligne ?
En html, le texte étant contenu dans un conteneur de type block, le nombre de caractères affichés sur une ligne dépend donc de la largeur du conteneur.
Avec le design responsive, la largeur de conteneur qui affiche le contenu principal d’un site n’est généralement pas fixée via la propriété width. Par contre, la propriété utile ici pour éviter que le conteneur devienne trop large consiste à indiquer en css sa largeur maximale via la propriété max-width pour obtenir approximativement ces 80 caractères maximum en résultat.
On peut le faire en utilisant différentes unités, les plus communes étant « px », « em », « rem », il en existe d’autres dont l’unité « ch ». Je ne sais pas si cette unité est souvent utilisée dans les sites web, je n’en ai pas l’impression. Peut être à juste raison, mais j’ai testé pour voir.
Cette unité « ch » introduite en CSS3, est une unité de longueur relative à la largeur du caractère « 0 » (le zéro) de la police utilisée par l’élément courant.
En indiquant un max-width à 65ch, on doit donc s’attendre à obtenir 65 caractères de large, mais ce n’est pas tout à fait vrai. Le résultat d’une largeur en « ch » dépend aussi de la police de caractères sur laquelle on l’applique. Dans une police monospace où tous les glyphes sont de même largeur, le nombre de caractères sera bien le même que la valeur demandée. Pour les autres polices, on fait des tests pour ajuster. Ici, par exemple avec une font-family: verdana, je tombe à peu près dans les clous, sur 75 caractères pour une valeur de 65ch.
Cette unité est bien supportée par les différents navigateurs avec toutefois un comportement un peu différent sur IE. Voir sur Can I Use : ch
On peut donc tester, à voir ensuite sur quel conteneur l’appliquer.
.mon-conteneur {
max-width: 65ch;
margin: 0 auto;
}Un design de thème problématique
Pour élaborer l’apparence du thème Pixiscreen, le fait est que j’avais une idée assez floue au départ de ce que je voulais mettre en place. L’objectif principal était davantage de mettre en pratique des découvertes faites au fil de l’eau, sur d’autres sujets que le design.
Mais créer un design de thème à partir de zéro, sans trop savoir où on va, en se laissant porter par des découvertes, ça complique vraiment les choses, ce n’est pas une démarche très rationnelle.
Comme dirait l’autre, c’est mettre la charrue avant les bœufs !
Avant de lancer quoique ce soit comme ligne de code, un projet devrait être orienté par :
- une charte graphique,
- un cahier des charges fonctionnel et technique,
- des wireframes,
- des maquettes graphiques.
J’ai bien dessiné quelques wireframe pour dégager quelques idées. Mais rien de fixe, pour laisser place à l’intégration de nouveautés le cas échéant. C’est un carnet de bord d’expérimentations diverses après tout. Malgré tout, il faudra en passer par de la rationalisation de tout ça un jour où l’autre.
Le thème que j’ai mis en forme pour Pixi m’a imposé quelques contraintes que je n’ai pas trouvées facilement compatibles avec cette affaire de largeur de texte max de 80 caractères, parce que je n’y ai réfléchi qu’après coup.
Pourquoi l’apparence choisie pour Pixi m’a posé probème ?
Le menu de Pixi est dans un positionnement qui est différent en fonction de la taille de l’écran (en utilisant les positionnements flexbox).
En version desktop, j’ai souhaité que le menu s’affiche en fixe sur le côté gauche de l’écran, la partie concernant le contenu principal s’appliquant à sa droite, sur toute la place restante.
En ayant un contenu de type page ou de type article, sans sidebar, je me retrouve donc avec un espace disponible vraiment important en largeur. Limiter l’affichage du contenu dans cet espace pour qu’il n’excède pas 80 caractères par ligne fait qu’au niveau du rendu visuel c’est pas top du tout ! Le texte semble étriqué et perdu dans cet espace.
En ayant une navigation (un header) en haut de page, on a forcément encore plus d’espace me direz-vous. C’est vrai, mais visuellement l’impact est complètement différent. La vision est centrée, alors que dans mon cas la vision est forcée sur la largeur complète de l’écran à cause du header fixé à gauche.
Des design de thèmes similaires
Il existe des thèmes connus qui mettent en place le header sur la partie gauche de l’écran comme je l’ai fait ici pour Pixi. Alors comment gèrent ils ça ?
Les exemples qui suivent sont affichés sur une résolution d’écran de 1920px de large.
Le twenty fourteen
https://twentyfourteendemo.wordpress.com/
Pour le twenty fourteen, par défaut il ne remplit simplement pas la largeur complète de l’écran. L’affichage est limité en largeur sur le conteneur de la totalité du site par un max-width: 1260px. Il n’y a donc pas d’utilisation de cette unité ch, seule la taille du conteneur gère les choses.
Du coup c’est tout bon pour le nombre de caractères sur une ligne, avec en complément l’utilisation d’une sidebar qui permet de faire en sorte que l’espace disponible pour le contenu principal soit encore réduit. Le texte ne semble pas perdu dans la largeur de la page, tout est bien « rempli » !
Pour autant, cette façon de procéder ne me satisfait pas. Je trouve dommage de ne pas se servir de la totalité de la largeur de l’écran. Et puis, si j’ajoute une sidebar alors qu’à la base je ne veux pas de ce contenu complémentaire, j’en fais quoi ? Je rajoute du contenu que je n’estime pas forcément utile dedans, juste pour faire plus équilibré visuellement ? BOF !
Le twenty fifteen
https://twentyfifteendemo.wordpress.com/
Alors là, ils font comment eux ?
La largeur d’affichage de la page est comme dans le thème précédent, contrainte sur la largeur maximum de la totalité du site avec un max-width:1403px, et centrée (margin: 0 auto)), dans une media query concernant les grands écrans : @media screen and (min-width: 59.6875em). L’espace vide distribué est donc homogène.
Le nombre de caractères dans le contenu respecte bien la préconisation d’un maximum de caractères aux alentours de 75. Il ne provient pas non plus d’une unité « ch » appliquée au niveau du conteneur du texte principal, mais d’un effet cascade dû à la limitation de la largeur du site sur grand écran. Pour ma part, je trouve ça plus intéressant visuellement que ce qu’on vient de voir précédemment sur twenty fourteen.
Pour autant, ce n’est pas encore vraiment ça que je cherche. Je souhaite vraiment utiliser au maximum la largeur de l’écran. Un design qu’on appelle « full-width » ou « full-screen », avec mon header fixé sur la gauche de l’écran.
Restreindre la largeur de contenu principal sur Pixi
Pour le moment, sur Pixi, je tatonne encore. Il va falloir que j’analyse des sites qui utilise un design full-width pour essayer de dégager une « bonne pratique ».
Je suis sur une position de ne pas forcément mettre de sidebar sur toutes les pages du site, mais seulement quand ça me semble judicieux. Et ce contenu complémentaire selon moi ne devrait pas toujours être le même. WordPress permet de générer différentes sidebar qu’on ajoute selon la page sur laquelle on se trouve.
J’ai donc fait en sorte de limiter déjà le nombre de caractères de la partie principale, en utilisant l’espace par l’ajout d’un contenu complémentaire. Il est spécifique selon que l’on se retrouve sur un article, une page, une catégorie.
Contenu complémentaire à droite pour les articles
Pour les articles, je trouvais utile d’ajouter un sommaire pour que le visiteur puisse choisir plus rapidement l’endroit qu’il souhaite atteindre sans avoir à scroller la totalité de la page. L’endroit pour mon sommaire des articles était donc tout trouvé ! Pour créer ce sommaire j’ai suivi un tutoriel de Willy Bahuaud sur son site Wabeo : « Un sommaire pour vos articles sans plugin »
Il n’est affiché qu’en version desktop, sur mobiles cette fonctionnalité ne trouve pas sa place.
Contenu complémentaire à droite pour les catégories
Au niveau des catégories, placer quelques infos, des liens relatifs ça me parait intéressant, j’ai donc mis en place une sidebar spécifique selon la catégorie affichée.
Contenu complémentaire à droite pour les pages
Pour les pages, je reste toujours sur ma position de ne pas vouloir de sidebar, mais pas de sommaire non plus. Pourquoi pas de sommaire ? J’en sais trop rien, ce n’est pas un article, pas un tuto, je ne vois pas pour le moment ce que je pourrais ajouter comme contenu complémentaire. Mais quoi faire alors ?
La seule idée que j’ai eu pour le moment c’est de faire quand même une sidebar … mais au contenu uniquement décoratif, en attendant de trouver une meilleure idée. L’occasion de faire un peu d’animation en css3.
Quand je n’ai pas de sidebar spécifique à intégrer, c’est celle ci, avec ses petits carrés qui naviguent vers le haut de la page, qui s’affiche par défaut … Par contre, quand une sidebar contient des éléments qui n’apportent pas d’infos au lecteur, il faut faire en sorte qu’elle ne soit pas lue par les lecteurs d’écran pour ne pas polluer la lecture par des infos non utiles (ajout sur cet aside d’un aria-hidden = true).
Restriction du nombre de caractères via l’unité « ch »
La solution complémentaire à l’ajout d’élements en sidebar, c’est l’utilisation de cette unité « ch », même si ma police de caractères n’est pas monospace.
Elle est appliquée uniquement sur le conteneur :
- de l’article, pas son titre ou les métas.
- de la page, idem seulement le contenu.
Ça me va à peu près, juste une chose pour laquelle je ne suis pas convaincue : les césures que j’ai mises en place de façon globale sur le site. (Coupure de mots en fin de ligne avec ajout d’un tiret) Elles sont gérées via la propriété hyphens. Elle n’est pas encore bien supportée sous Chrome : Can I Use : hyphens. Elle est complétée avec word-wrap pour couper les mots longs.
Utilisé en tant que placeholder sous sass ça donne :
%breakword {
overflow-wrap: break-word;
word-wrap: break-word;
-ms-word-break: break-all;
word-break: break-word;
-ms-word-wrap: break-word;
/* Adds a hyphen where the word breaks, if supported (No Blink) */
-ms-hyphens: auto;
-webkit-hyphens: auto;
hyphens: auto;
}
// Exemple usage :
// .widget {
// @extend %breakword;
// }Le résultat c’est que sous Firefox, beaucoup de mots se retrouvent coupés d’une façon qui parait très aléatoire, et ce n’est pas très compatible avec l’accessibilité. Dans le cas de la dyslexie, un morceau de mot n’a pas beaucoup de sens … la contrainte de rechercher sa suite sur la bonne ligne pour le reconstituer etc … peut devenir laborieuse.
La question est donc : Supprimer les césures ? Si oui, la belle échelle provoquée en fin de chaque ligne est-elle gênante ? De toute façon sous Chrome les césures ne sont pas effectives.
Pour ne pas avoir cet effet d’échelle, utiliser la règle css : text-align : justify ?
Je n’ai pas décidé pour le moment.
To be continued …