1 points par GN⁺ 2024-08-28 | 1 commentaires | Partager sur WhatsApp
  • Il s’agit d’une page expérimentale qui aligne les éléments du web sur une grille de caractères, afin d’afficher texte, tableaux, diagrammes et médias dans une esthétique proche des terminaux des années 1970
  • De simples documents Markdown sont convertis avec Pandoc, puis du HTML sémantique est rendu sur une grille monospace avec du CSS et très peu de JavaScript
  • Le comportement responsive ne se réduit pas en pixels mais en unités de taille de caractère ; les tableaux s’ajustent automatiquement à la grille, mais une seule colonne peut être extensible
  • La page gère des éléments standards comme les paragraphes, séparateurs, <details>, listes, listes en arborescence, tableaux, formulaires, conteneurs grid, dessins ASCII basés sur <pre>, ainsi que les images et vidéos
  • L’intégralité du code source est publiée sur GitHub, et il est possible de forker ou de copier les parties nécessaires dans le respect des conditions de licence

Une page web construite sur une grille de caractères

  • Les polices monospace peuvent sembler à certains utilisateurs plus lisibles, plus cohérentes et plus élégantes que les polices à chasse proportionnelle
  • Cette page est une expérimentation technique et créative visant à composer tous les éléments avec une approche web monospace
  • L’implémentation consiste à convertir un document Markdown avec Pandoc, puis à positionner le HTML sémantique sur une grille de caractères à l’aide de CSS et d’un peu de JavaScript
  • La mise en page responsive s’adapte à la largeur de l’écran en se réduisant en unités de taille de caractère plutôt qu’en pixels
  • L’objectif est de faire en sorte que les éléments HTML standards fonctionnent naturellement à l’intérieur d’une grille monospace, sans travail complexe supplémentaire

Éléments pris en charge et mode de disposition

  • Le balisage de base inclut des paragraphes ordinaires, des séparateurs horizontaux et l’élément <details>
  • Les listes prennent en charge les listes à puces et les listes ordonnées, et une liste non ordonnée avec la classe tree permet de représenter une structure arborescente semblable à un système de fichiers
  • Les tableaux s’ajustent automatiquement à la grille monospace et restent responsives
    • Toutefois, une seule colonne peut être extensible
  • Les formulaires sont également pris en charge et disposés sur la même grille de caractères que les autres éléments standards
  • En ajoutant la classe grid à un conteneur, les cellules se partagent équitablement l’espace horizontal
    • Comme les propriétés monospace sont conservées, la largeur totale n’atteint pas toujours 100 %
    • Pour qu’une cellule donnée occupe l’espace restant, il faut lui appliquer flex-grow: 1;
  • Il est possible de créer des dessins de style ASCII à l’aide de la balise <pre> et des caractères de dessin de boîte
    • On peut les envelopper dans <figure> et <figcaption> pour les mettre davantage en valeur
    • Les exemples incluent un diagramme de transmission de messages et un histogramme
  • Les objets média comme les images et les vidéos sont aussi pris en charge
    • Ils s’étendent jusqu’à la largeur de la page, avec un padding inférieur ajouté pour préserver la grille monospace
  • L’intégralité du code source est disponible sur github.com/owickstrom/the-monospace-web
  • L’inspiration du design vient de U.S. Graphics Company

1 commentaires

 
GN⁺ 2024-08-28
Avis de Hacker News
  • Je rassemble une liste de pages en chasse fixe : https://wonger.dev/posts/monospace-dump#web. Pour l’instant, il y en a une cinquantaine
    La gestion de l’espacement est difficile, et en renonçant aux polices proportionnelles, on perd aussi une certaine lisibilité
    Je pense que le crénage des polices proportionnelles fait une grande différence dans la façon dont l’œil reconnaît la forme des groupes de lettres
    Le texte en chasse fixe convient dans des endroits structurés et avec coloration comme un éditeur de code, mais il vaut mieux l’éviter pour les longs textes
    Cela dit, c’est vraiment joli, surtout pour les tableaux Unicode et l’art ASCII

    • Dans les polices proportionnelles, le crénage fait une différence énorme. Un bon crénage permet au cerveau de traiter la forme des mots beaucoup plus vite
    • L’art ASCII était vraiment génial. En cours de dactylo, une fois le travail du jour terminé, on pouvait créer de l’art ASCII en suivant une liste d’instructions sans connaître l’image finale
      Par exemple 15 space, 1 V, 3 U, 1 V, 15 space, 5 U, 12 space, 2 x, 5 U, 2 x, et au bout d’environ 250 lignes apparaissait une image de Jordan en train de dunker, qu’on pouvait imprimer
    • L’un des exemples est désormais un domaine à vendre. Il reste toutefois dans la WBM : https://web.archive.org/web/20230216225350/https://kary.us/n...
    • Les couleurs et le texte en chasse fixe avec peu de mise en forme donnent l’impression d’abandonner une dimension sensorielle ou spatiale. Cela tient presque d’un ascétisme sans intérêt
    • Un autre élément à ajouter à la liste :) https://jarek.lupin.ski/tape-deck/
  • Ce fil semble parfait pour poser cette question. Il y a quelques années, j’avais vu un texte, probablement une soluce de jeu vidéo, écrit pour être lu en police à chasse fixe, et dont les milliers de lignes étaient parfaitement justifiées des deux côtés uniquement par le choix des mots
    Quelqu’un sait de quoi il s’agit et aurait un lien ?

    • Dans le même genre, il y a aussi http://tom7.org/bovex/. C’est un moteur de mise en page qui remplace l’entrée par un LLM pour obtenir un effet similaire
    • Ça s’appelle du bricktext. On en voyait parfois autrefois sur usenet ou GameFAQs
      [0] http://www.catb.org/esr/jargon/html/B/bricktext.html
      C’est assez surprenant que ce concept ait complètement disparu des résultats de recherche Google
    • Laravel fait quelque chose de similaire. Dans un commentaire sur plusieurs lignes, chaque ligne est exactement 3 caractères plus courte que la précédente
      https://github.com/laravel/laravel/blob/11.x/config/database...
    • J’ai un vague souvenir d’avoir vu ça dans des soluces GameFAQs. C’était peut-être un jeu Final Fantasy, mais je ne me souviens de rien de plus
    • Moi aussi, j’aimerais ajouter une question à ce fil
      Depuis des années, j’ai envie de créer une extension Visual Studio Code qui justifierait les commentaires pendant la frappe, avec césure, tout en autorisant des espaces supplémentaires si nécessaire
      À part chercher quelques algorithmes et bibliothèques liés au sujet, je ne m’y suis pas mis, parce que ça semblait assez complexe
      J’ai essayé d’utiliser des choses comme fmt ou par, mais j’ai fini par accepter que, sauf à le faire manuellement, il fallait renoncer aux commentaires joliment alignés, et qu’une petite modification oblige souvent à retravailler plusieurs lignes, ce qui prend trop de temps
      Les identifiants longs, si possible, je ne veux pas les couper en plein milieu de ligne, et il faudrait aussi gérer les listes imbriquées, les tableaux, les blocs de code, l’art ASCII dans les commentaires, la distinction entre tirets internes aux mots et traits d’union ajoutés par césure, ainsi que les commentaires structurés comme les commentaires de documentation XML ou les balises Javadoc
      En voyant Badness 0 de Tom7, j’ai aussi pensé à lui lancer un LLM, mais si cela doit fonctionner en temps réel et sans commentaires hallucinés, je ne pense pas que ce soit encore praticable
      Est-ce qu’une telle fonctionnalité existe déjà, ou existe-t-il une base qui éviterait que créer cette extension devienne un chantier d’un an ?
  • La chasse fixe en soi ne me dérange pas
    Ce qui me dérange, ce sont les retours à la ligne forcés
    Certains sites « rétro » utilisent en fait une balise pre
    Sur téléphone, cela devient un mur de texte en petits caractères, le mode lecture ne fonctionne pas, et en orientation paysage on peut se retrouver, ou non, avec une barre de défilement
    C’est aussi à peu près mon seul reproche aux listes de diffusion techniques actuelles : les retours à la ligne forcés et les mises en page rigides

    • Ce site web ne fait pas ça. Il est entièrement responsive
    • J’ai essayé de lire un RFC sur téléphone, et je devais sans cesse faire défiler horizontalement pour voir un simple paragraphe. Sinon, il fallait réduire le texte au point qu’il devenait illisible
    • Je me demande ce qui pose exactement problème avec une barre de défilement
  • Dans une vidéo vue aujourd’hui, ils appelaient ça le web indé, une philosophie qui consiste à s’opposer aux algorithmes et à embrasser ce qui rendait le web d’autrefois formidable
    Des choses comme RSS, les blogs personnels, les forums et les webrings
    J’en ai moi-même lancé un, et c’est plutôt agréable

  • C’est agréable à regarder, sémantique et responsive, mais fondamentalement, une police à chasse fixe n’est pas idéale pour le texte courant
    J’ai lu des billets de blog en texte courant à chasse fixe sur plusieurs sites, et ça passait, mais selon moi une police proportionnelle est la bonne direction

    • Je crois que je préfère la chasse fixe. Au moins, le jeu de couleurs texte blanc sur fond noir est clairement meilleur
      Je trouve ça bien supérieur à ces « belles » pages qui essaient de recréer l’ambiance des anciens magazines imprimés
    • D’accord. Ça a aussi commencé à me gêner quand j’écris des documents Markdown, mais avec Markdown il est souvent irréaliste d’éviter la chasse fixe
    • Par curiosité, quelle police préfères-tu pour le texte courant ?
      Sur mon blog, j’utilise une chasse fixe parce que j’ai une mauvaise vue et que j’utilise des réglages de zoom, mais comme l’accessibilité me tient à cœur, je me demande toujours quel choix serait le plus lisible pour tout le monde
  • Quoi qu’il en soit, je trouve que la classe CSS tree ul-list est assez bonne pour mériter d’entrer dans la spécification HTML comme balise. C’est un composant extrêmement utile

  • L’interligne est trop serré, ce qui nuit à la lisibilité. Les longs paragraphes de texte aussi denses sont difficiles à lire
    Mais les tableaux et les graphismes en caractères ont besoin de cet interligne réduit
    Le problème est d’utiliser la même grille de caractères à la fois pour les graphismes et pour le texte
    Cela pourrait être atténué en utilisant une police avec une x-height particulièrement basse, qui laisse davantage d’espace au-dessus et au-dessous des lettres

    • Au début, j’ai cru que tu parlais de la largeur de ligne, ce qui m’a embrouillé. La largeur de ligne est dans une plage généralement acceptée, autour de 70 caractères
      Pour la hauteur de ligne, je suis d’accord. Avec une taille de police de 16 px et 19,2 px, ça ne fait que 1,2×, donc c’est trop étouffant. Passer à 24 px améliore nettement les choses
      Cela dit, à mes yeux, une hauteur de ligne plus grande ne semble pas affecter les tableaux ni les graphismes en caractères. Avec ce réglage, le style à chasse fixe s’en sort plutôt bien
      Édition : je crois comprendre l’idée. Ça casse le concept de grille fixe de l’auteur. On peut le vérifier en mettant line-height: 24px sur les éléments p et en activant le « debug mode » de l’auteur pour afficher la grille
    • Comme je ne supporte vraiment pas la chasse fixe pour la lecture, j’ai créé un bookmarklet. Sur ce site, il suffit de passer les balises de texte ordinaires en sans-serif pour que ça fonctionne bien, alors que tous les modes lecture bousillent les préférences de police
      javascript: (function() {
      (function() {
      const textElements = document.querySelectorAll('p, span, h1, h2, h3, h4, h5, h6, li, td, th');
      textElements.forEach((element) => {
      const textColor = getComputedStyle(element).getPropertyValue('color');
      element.style.fontFamily = 'system-ui, -apple-system, sans-serif';
      element.style.WebkitTextStroke = \0.4px ${textColor}`; }); location.hash = ""; history.replaceState("", "", location.pathname); })(); })();`
      https://caiorss.github.io/bookmarklet-maker/
    • Comparé à la densité des commentaires HN ici, ça donne quoi ?
    • Le problème vient-il de la hauteur de ligne trop serrée, ou du fait même qu’une police à chasse fixe est plus difficile à lire qu’une police proportionnelle ?
      Les mots en chasse fixe finissent en effet par avoir des « formes » plus semblables que les mots en police proportionnelle
    • J’ai eu un rejet immédiat dès que je l’ai vu
  • OpenBSD a commencé il y a quelques années à définir Spleen comme police de console
    Dommage qu’il n’y ait pas de version TrueType
    https://github.com/fcambus/spleen

    • On ne peut pas utiliser les fichiers OTF à la place ? Le README indique qu’il y a des fichiers OTF dans le tarball de release
  • Le fameux VIC article, une ressource C64 encore connue aujourd’hui, est proposé en chasse fixe
    https://www.cebix.net/VIC-Article.txt
    Le principal problème, c’est la sortie
    Cet article utilise des diagrammes qui nécessitent des repères fixes dans un espace à deux dimensions ; ici, la chasse fixe est donc très importante
    C’est l’une des références techniques les plus importantes sur le C64, et 99 % des effets de démo techniques peuvent être décomposés en astuces de base qui s’y trouvent

  • J’envisage de passer la police de mon site perso en chasse fixe
    Quelqu’un connaît une police à chasse fixe particulièrement bonne pour la lisibilité des longs textes ?
    Ce serait encore mieux si elle était sur Google Fonts

    • Pour l’affichage des paragraphes, j’aime bien Drafting Mono : https://indestructibletype.com/Drafting/
      Elle n’est pas sur Google Fonts, mais elle est gratuite, ou alors la version en police variable est très abordable
    • IBM Plex Mono est plutôt bonne et sa licence est raisonnable. Elle est sur Google Fonts, et le dépôt est ici : https://github.com/IBM/plex
    • Digression, mais tu pourrais envisager d’utiliser https://fontsource.org/ plutôt que Google Fonts. C’est tout aussi facile à utiliser, et au moins il n’y a pas de pistage Google