Techniques de pleine conscience et de méditation pour les développeurs : Améliorer la concentration et la clarté

Jusqu'à présent, essayer de styliser un article, un document ou un billet de blog avec Tailwind était une tâche fastidieuse qui nécessitait un œil aiguisé pour la typographie et beaucoup de CSS personnalisé complexe.

Par défaut, Tailwind supprime tous les styles de navigateur par défaut des paragraphes, des titres, des listes et plus encore. Cela s'avère vraiment utile pour construire des interfaces utilisateur d'applications car vous passez moins de temps à annuler les styles de l'agent utilisateur, mais lorsque vous essayez vraiment de styliser du contenu provenant d'un éditeur de texte riche dans un CMS ou d'un fichier markdown, cela peut être surprenant et contre-intuitif.

Nous recevons beaucoup de plaintes à ce sujet, avec des personnes qui nous demandent régulièrement des choses comme :

Pourquoi Tailwind supprime-t-il les styles par défaut sur mes éléments h1 ? Comment puis-je désactiver cela ? Que voulez-vous dire par "je perds aussi tous les autres styles de base" ? Nous vous entendons, mais nous ne sommes pas convaincus que la simple désactivation de nos styles de base est ce que vous voulez vraiment. Vous ne voulez pas avoir à supprimer les marges ennuyeuses chaque fois que vous utilisez un élément p dans une partie de votre interface utilisateur de tableau de bord. Et je doute que vous vouliez vraiment que vos articles de blog utilisent les styles de l'agent utilisateur non plus — vous voulez qu'ils soient superbes, pas affreux.

Le plugin @tailwindcss/typography est notre tentative de vous donner ce que vous voulez réellement, sans aucun des inconvénients de faire quelque chose de stupide comme désactiver nos styles de base.

Il ajoute une nouvelle classe prose que vous pouvez appliquer à n'importe quel bloc de contenu HTML vanilla et le transformer en un document beau et bien formaté :

<article className="prose">
  <h1>Pain à l'ail avec du fromage : Ce que nous dit la science</h1>
  <p>
    Pendant des années, les parents ont vanté les bienfaits pour la santé de manger du pain à l'ail
    avec du fromage à leurs enfants, la nourriture ayant acquis un statut si emblématique
    dans notre culture que les enfants se déguisent souvent en pain chaud et fromagé pour
    Halloween.
  </p>
  <p>
    Mais une étude récente montre que cette entrée célèbre pourrait être liée à une
    série de cas de rage qui surgissent dans tout le pays.
  </p>
</article>

Pour plus d'informations sur l'utilisation du plugin et ses fonctionnalités, lisez la documentation.

À quoi s'attendre à partir de maintenant

Ce qui suit n'est qu'un tas de non-sens absolu que j'ai écrit pour tester le plugin lui-même. Il inclut tous les éléments typographiques sensés auxquels j'ai pu penser, comme le texte en gras, les listes non ordonnées, les listes ordonnées, les blocs de code, les citations, et même l'italique. <h3>Ceci est du code en ligne</h3>

Il est important de couvrir tous ces cas d'utilisation pour plusieurs raisons :

1. Nous voulons que tout soit beau par défaut.
2. Vraiment juste la première raison, c'est tout l'intérêt du plugin.
3. Voici une troisième raison fictive, mais une liste avec trois éléments semble plus réaliste qu'une liste avec deux éléments.

Maintenant, nous allons essayer un autre style d'en-tête.

La typographie devrait être facile

Voilà donc un en-tête pour vous — avec un peu de chance, si nous avons bien fait notre travail, cela devrait paraître assez raisonnable.

Quelque chose qu'une personne sage m'a dit un jour sur la typographie :

La typographie est assez importante si vous ne voulez pas que vos trucs ressemblent à des déchets. Faites-la bien et elle ne sera pas mauvaise.

Il est probablement important que les images soient correctes ici par défaut également :

Contrairement à la croyance populaire, Lorem Ipsum n'est pas simplement du texte aléatoire. Il a ses racines dans un morceau de littérature latine classique datant de 45 av. J.-C., ce qui le rend vieux de plus de 2000 ans.

Maintenant, je vais vous montrer un exemple de liste non ordonnée pour m'assurer que cela a l'air bien aussi :

• Voici donc le premier élément de cette liste.
• Dans cet exemple, nous gardons les éléments courts.
• Plus tard, nous utiliserons des éléments de liste plus longs et plus complexes.

Et c'est la fin de cette section.

Et si nous empilons les titres ?

Nous devrions nous assurer que cela a l'air bien aussi.

Parfois, vous avez des titres directement l'un sous l'autre. Dans ces cas, vous devez souvent annuler la marge supérieure du deuxième titre car il est généralement préférable que les titres soient plus proches l'un de l'autre qu'un paragraphe suivi d'un titre ne devrait l'être.

Quand un titre vient après un paragraphe …

Quand un titre vient après un paragraphe, nous avons besoin d'un peu plus d'espace, comme je l'ai déjà mentionné ci-dessus. Maintenant, voyons à quoi ressemblerait une liste plus complexe.

• Je fais souvent cette chose où les éléments de liste ont des titres.

  Pour une raison quelconque, je pense que cela a l'air cool, ce qui est malheureux car c'est assez ennuyeux d'obtenir les styles corrects.

  J'ai souvent deux ou trois paragraphes dans ces éléments de liste aussi, donc la partie difficile est d'obtenir l'espacement entre les paragraphes, le titre de l'élément de liste et les éléments de liste séparés pour que tout ait du sens. Assez difficile honnêtement, vous pourriez faire un argument solide que vous ne devriez simplement pas écrire de cette façon.

• Puisque c'est une liste, j'ai besoin d'au moins deux éléments.

  J'ai déjà expliqué ce que je fais dans l'élément de liste précédent, mais une liste ne serait pas une liste si elle n'avait qu'un seul élément, et nous voulons vraiment que cela semble réaliste. C'est pourquoi j'ai ajouté ce deuxième élément de liste pour que j'aie réellement quelque chose à regarder en écrivant les styles.

• Ce n'est pas une mauvaise idée d'ajouter un troisième élément non plus.

  Je pense que ça aurait probablement été bien d'utiliser juste deux éléments mais trois n'est définitivement pas pire, et puisque je semble n'avoir aucun mal à inventer des choses arbitraires à taper, je pourrais aussi bien l'inclure.

Après ce genre de liste, j'ai généralement une déclaration ou un paragraphe de clôture, car ça semble un peu bizarre de passer directement à un titre.

Le code devrait avoir l'air correct par défaut.

Je pense que la plupart des gens vont utiliser highlight.js ou Prism ou quelque chose comme ça s'ils veulent styliser leurs blocs de code, mais ça ne ferait pas de mal de les faire paraître corrects par défaut, même sans coloration syntaxique.

Voici à quoi ressemble un fichier tailwind.config.js par défaut au moment de l'écriture :

module.exports = {
  purge: [],
  theme: {
    extend: {},
  },
  variants: {},
  plugins: [],
}

J'espère que cela vous semble assez bien.

Et les listes imbriquées ?

Les listes imbriquées ont presque toujours l'air mauvaises, c'est pourquoi des éditeurs comme Medium ne vous laissent même pas le faire, mais je suppose que puisque certains d'entre vous vont le faire, nous devons porter le fardeau de le faire fonctionner au moins.

1. Les listes imbriquées sont rarement une bonne idée.
   • Vous pourriez avoir l'impression d'être vraiment "organisé" ou quelque chose comme ça, mais vous créez juste une forme grossière à l'écran qui est difficile à lire.
   • La navigation imbriquée dans les interfaces utilisateur est aussi une mauvaise idée, gardez les choses aussi plates que possible.
   • L'imbrication de tonnes de dossiers dans votre code source n'est pas non plus utile.
2. Puisque nous devons avoir plus d'éléments, en voici un autre.
   • Je ne sais pas si nous nous donnerons la peine de styliser plus de deux niveaux de profondeur.
   • Deux c'est déjà trop, trois est garanti d'être une mauvaise idée.
   • Si vous imbriquez quatre niveaux de profondeur, vous méritez d'aller en prison.
3. Deux éléments ne font pas vraiment une liste, trois c'est bien par contre.
   • Encore une fois, s'il vous plaît, n'imbriquez pas les listes si vous voulez que les gens lisent réellement votre contenu.
   • Personne ne veut regarder ça.
   • Je suis contrarié que nous devions même nous soucier de styliser ça.

La chose la plus ennuyeuse à propos des listes en Markdown est que les éléments <li> ne reçoivent pas de balise <p> enfant à moins qu'il n'y ait plusieurs paragraphes dans l'élément de liste. Cela signifie que je dois aussi m'inquiéter du style de cette situation ennuyeuse.

• Par exemple, voici une autre liste imbriquée.

  Mais cette fois avec un deuxième paragraphe.

  • Ces éléments de liste n'auront pas de balises <p>
  • Parce qu'ils n'ont qu'une seule ligne chacun

• Mais dans ce deuxième élément de liste de premier niveau, ils en auront.

  C'est particulièrement ennuyeux à cause de l'espacement sur ce paragraphe.

  • Comme vous pouvez le voir ici, parce que j'ai ajouté une deuxième ligne, cet élément de liste a maintenant une balise <p>.

    C'est la deuxième ligne dont je parle d'ailleurs.

  • Enfin, voici un autre élément de liste pour que ce soit plus comme une liste.

• Un élément de liste de clôture, mais sans liste imbriquée, parce que pourquoi pas ?

Et enfin une phrase pour clore cette section.

Il y a d'autres éléments que nous devons styliser

J'ai presque oublié de mentionner les liens, comme ce lien vers le site web de Tailwind CSS. Nous les avons presque faits bleus mais c'est tellement dépassé, donc nous avons opté pour le gris foncé, ça fait plus tendance.

Nous avons même inclus des styles de tableau, regardez :

Nous devons aussi nous assurer que le code en ligne a l'air bien, comme si je voulais parler des éléments <span> ou vous dire la bonne nouvelle à propos de @tailwindcss/typography.

Parfois j'utilise même du code dans les titres

Même si c'est probablement une mauvaise idée, et historiquement j'ai eu du mal à le faire paraître bien. Cette astuce de "mettre les blocs de code entre des backticks" fonctionne plutôt bien cependant.

Une autre chose que j'ai faite dans le passé est de mettre une balise code à l'intérieur d'un lien, comme si je voulais vous parler du dépôt tailwindcss/docs. Je n'aime pas qu'il y ait un soulignement sous les backticks mais ce n'est absolument pas la peine de la folie qu'il faudrait pour l'éviter.

Nous n'avons pas encore utilisé de h4

Mais maintenant nous l'avons fait. S'il vous plaît, n'utilisez pas de h5 ou h6 dans votre contenu, Medium ne supporte que deux niveaux de titres pour une raison, vous les animaux. J'ai honnêtement envisagé d'utiliser un pseudo-élément before pour vous crier dessus si vous utilisez un h5 ou h6.

Nous ne les stylisons pas du tout par défaut car les éléments h4 sont déjà si petits qu'ils sont de la même taille que le texte du corps. Que sommes-nous censés faire avec un h5, le rendre plus petit que le texte du corps ? Non merci.

Nous devons encore penser aux titres empilés.

Assurons-nous de ne pas gâcher ça avec les éléments h4 non plus.

Ouf, avec un peu de chance, nous avons stylisé les titres au-dessus de ce texte et ils ont l'air plutôt bien.

Ajoutons un paragraphe de clôture ici pour que les choses se terminent par un bloc de texte de taille décente. Je ne peux pas expliquer pourquoi je veux que les choses se terminent de cette façon, mais je dois supposer que c'est parce que je pense que les choses sembleront bizarres ou déséquilibrées s'il y a un titre trop proche de la fin du document.

Ce que j'ai écrit ici est probablement assez long, mais ajouter cette dernière phrase ne peut pas faire de mal.

Markdown GitHub Flavored

J'ai également ajouté le support pour GitHub Flavored Markdown en utilisant remark-gfm.

Avec remark-gfm, nous obtenons quelques fonctionnalités supplémentaires dans notre markdown. Exemple : les littéraux de lien automatique.

Un lien comme www.example.com ou https://example.com serait automatiquement converti en balise a.

Cela fonctionne aussi pour les liens email : contact@example.com.