readable.css

 (readable-css.freedomtowrite.org)
2 points par GN⁺ 8 시간 전 | 1 commentaires | Partager sur WhatsApp
  • readable.css n’est pas un système de design complet pour l’ensemble d’un site, mais un framework CSS qui ajoute des styles de base raisonnables et agréables à du HTML sémantique
  • Son principe central est la cohérence : couleurs, styles typographiques, épaisseur des bordures et hauteur de ligne sont appliqués de façon harmonisée sur tout le site
  • Il propose un mode clair/sombre, un design responsive, un rythme vertical, ainsi que des styles pour l’en-tête, le pied de page, la navigation, les tableaux, les boutons et les formulaires
  • Il n’inclut pas d’animations tape-à-l’œil, de polices personnalisées, de classes utilitaires, ni d’éléments qui écrasent les réglages du navigateur de l’utilisateur
  • Il part du principe d’un HTML sémantique, interprète l’intention en conséquence, prend en charge Firefox 84+, Chromium 88+, Edge 88+, Safari 10+ et exclut IE

Principales fonctionnalités et périmètre de conception

  • readable.css n’est pas un framework destiné à créer un système de design complet pour tout un site, mais un framework CSS qui rend le HTML de base raisonnable et agréable à regarder
  • Il prend en charge le mode clair/sombre manuellement ou via prefers-color-scheme, et fournit un design responsive ainsi qu’un rythme vertical
  • Il applique des styles à l’en-tête, au pied de page, à la barre de navigation, aux images, aux citations, aux aside, aux tableaux, aux boutons et aux formulaires
  • La justification du texte est désactivée par défaut, et les polices natives comme serif, sans-serif et monospace sont prises en charge
  • Les animations tape-à-l’œil, les polices personnalisées, les classes utilitaires et les éléments qui écrasent les réglages du navigateur de l’utilisateur sont volontairement exclus

Utilisation et prise en charge

  • Le dernier fichier CSS peut être téléchargé depuis la page des releases puis ajouté au site 
    <link rel="stylesheet" type="text/css" href="/path/to/readable.css">
  • readable.css interprète l’intention du site selon la manière dont l’HTML sémantique est utilisé ; pour exploiter correctement la feuille de style, il faut donc employer correctement le HTML sémantique
  • Le guide d’utilisation et la manière d’écrire du HTML adapté à readable.css sont disponibles sur le wiki
  • Firefox 84+, Chromium 88+, Edge 88+, Safari 10+ sont pris en charge, et IE n’est pas pris en charge
  • Pour Chromium, Firefox et Edge, le facteur limitant est la prise en charge de :not() et :is() ; pour Safari, c’est la prise en charge des variables CSS
  • Le code source se trouve sur Codeberg, et la documentation est fournie dans les Docs
  • readable.css et le code du site sont sous licence 0BSD et peuvent être utilisés à n’importe quelle fin sans attribution obligatoire
  • Freedom to Write est un mouvement qui crée et soutient des solutions logicielles libres et open source pour l’industrie de l’écriture

À lire aussi

1 commentaires

 
GN⁺ 8 시간 전
Avis sur Lobste.rs

  • J’aime le fait qu’ils ne touchent pas à la valeur de base de font-size. Les utilisateurs peuvent, et devraient, définir leur taille préférée dans leur agent utilisateur, par exemple le navigateur, et les sites web doivent respecter ce choix
    Je déteste le 12px fixe parce que c’est trop petit, et je ne veux pas non plus que le texte grossisse soudainement sur les grands viewports alors que je l’ai déjà réglé à une taille confortable. C’est beaucoup trop fréquent et cela nuit fortement à l’accessibilité

    • Même sur des projets pro, quand j’essaie de faire respecter des standards comme Accept-Language, on me répond souvent que les utilisateurs ne sauront pas configurer l’app correctement et qu’il faut donc le faire à leur place
      J’imagine qu’on entendra le même genre d’argument pour la taille de police

  • Je regarde toujours des frameworks comme PicoCSS ou MVP, et celui-ci a attiré mon attention parce qu’il semble conçu pour servir de point de départ
    On dirait une bonne base sur laquelle construire, mais j’aimerais aussi avoir l’avis de personnes qui s’y connaissent mieux en design

  • L’approche qui consiste à changer des variables CSS via html[data-font-family="serif"] n’est pas très utile. Autant permettre simplement d’utiliser <html style="font-family:serif">, c’est presque aussi facile côté templates que côté scripts client, tout en étant plus court et moins complexe
    Dans sa forme actuelle, cela peut laisser croire qu’on peut écrire <html data-font-family="some-webfont, serif">, alors qu’en réalité cela ne fonctionnera pas. Utiliser monospace comme police pour tout un document est aussi un choix de style peu compatible avec la lisibilité, et cela colle mal avec le nom “readable.css”. Cela dit, j’apprécie la retenue qui consiste à se limiter à une seule famille de polices générique
    --line-width et --line-height portent aussi à confusion. Un “line” désigne tantôt une ligne entre des éléments, tantôt une ligne de texte
    Côté thèmes de couleur, l’ensemble (prefers-color-scheme) et (prefers-contrast), [data-theme], [data-high-contrast] est embrouillé, et certaines valeurs ainsi que leurs interactions ne sont pas documentées. La combinaison @media (prefers-contrast: more) and (prefers-color-scheme: dark) donne un fond #fff avec du texte #000 quand il n’y a pas d’override <html data-*>, ce qui est clairement cassé. Il faut aussi des déclarations color-scheme: dark et color-scheme: light
    À a { color: inherit; }, je n’avais déjà plus envie de continuer à regarder. Même sans parler de la prétention au rythme vertical, si on fait hériter la couleur des liens et qu’on enlève en plus le soulignement dans la navigation, beaucoup d’utilisateurs ne verront même pas qu’il y a des liens. Les liens devraient être bleus, ou au minimum avoir une couleur d’accent saturée, et rester soulignés. C’est d’autant plus décevant vu le nom readable.css

    • La lisibilité est un domaine étudié depuis des décennies et assez bien compris, pourtant beaucoup de gens la maîtrisent mal. Les erreurs les plus fréquentes concernent surtout la longueur de ligne et le choix de la police, mais il y a aussi la taille du texte, l’interlignage, le contraste, etc.
      La longueur de ligne a une plage minimale et maximale dans laquelle la plupart des gens lisent confortablement, soit environ 50 à 70 caractères par ligne. Ce fil Stack Exchange contient de bonnes réponses, et c’est proche de l’accessibilité puisque les WCAG du W3C, dans la section visual presentation, parlent d’une « largeur de 80 caractères ou glyphes maximum (40 maximum pour le CJK) »
      Pour les polices, les sans serif sont en général les plus lisibles sur le plus grand nombre d’écrans, et sur les écrans modernes haute résolution, les serif sont globalement jugées comparables. Les polices à chasse fixe réduisent la lisibilité pour la plupart des gens et sont donc rarement un bon choix pour le corps du texte. Les exceptions peuvent être les personnes très habituées aux terminaux et éditeurs de code, ou parfois des personnes dyslexiques qui lisent plus facilement certaines polices monospace. En cas de doute, Arial est un choix sûr, même peu enthousiasmant, et on peut aussi consulter ce fil Stack Exchange sur les polices monospace
      À cela s’ajoutent la page typography du gouvernement américain, la section typography de BBC GEL, la section typography de Google Material Design, Butterick's Practical Typography pour aller plus loin, ainsi que The Elements of Typographic Style Applied to the Web

  • Franchement, la taille de texte par défaut est trop petite et difficile à lire. Je ne comprends pas pourquoi ce choix a été fait, et pour moi ce n’est bon ni pour l’accessibilité ni pour la lisibilité

    • Cela vient de deux problèmes de la plateforme web. Suivre la police et la taille fournies par le navigateur est une bonne chose en ce sens que cela respecte une préférence utilisateur explicite, mais en pratique très peu d’utilisateurs définissent explicitement leurs préférences, et dans beaucoup de configurations par défaut les éditeurs de navigateurs n’ont pas changé des valeurs par défaut historiques, si bien que la taille obtenue reste proche de la limite basse de lisibilité
      Plus embêtant encore, font-size n’a pas de signification absolue stable d’une police à l’autre. Même font-size: 16px peut rendre très différemment selon la police choisie. Dans Safari, les valeurs par défaut sans et sans-serif ont cet écart visuel : https://github.com/user-attachments/assets/…. On peut aussi voir dans ce commentaire que la taille de la police monospace ne correspond pas aux autres
      Au final, c’est difficile à corriger proprement, quelque chose cassera toujours quelque part, et cela relève surtout du compromis que préfère le webmaster. Personnellement, quand je peux utiliser le mode lecture, je fais peu attention au design du site. En revanche, il existe aujourd’hui une solution assez pratique au flou de font-size : https://matklad.github.io/2025/07/16/font-size-adjust.html
    • J’utilise un étrange écran 140 ppi, et le zoom à 125% qu’il faudrait théoriquement appliquer rend mal, donc je reste à 100% et j’ajuste le zoom par défaut pour pouvoir lire
      Le texte de ce site était si petit que je me suis demandé s’il contournait ce zoom. J’ai encore dû augmenter d’un cran la taille minimale de police dans Firefox