Guide de style

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

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

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

Pourquoi Tailwind supprime-t-il les styles par défaut de mes éléments h1 ? Comment désactiver cela ? Que voulez-vous dire par perdre tous les autres styles de base aussi ? Nous vous entendons, mais nous ne sommes pas convaincus que désactiver simplement nos styles de base soit ce que vous voulez vraiment. Vous ne voulez pas avoir à supprimer des marges gênantes chaque fois que vous utilisez un élément p dans une partie de l'interface de votre tableau de bord. Et je doute que vous vouliez vraiment que vos billets de blog utilisent les styles des agents utilisateurs non plus — vous voulez qu'ils soient superbes, pas affreux.

Le plugin @tailwindcss/typography est notre tentative de vous donner ce que vous voulez vraiment, 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 standard pour le transformer en un document magnifique et bien formaté :

<article class="prose">
  <h1>Pain à l'ail avec fromage : Ce que la science nous dit</h1>
  <p>Depuis des années, les parents vantent les bienfaits pour la santé de manger du pain à l'ail avec du fromage à leurs enfants, ce plat ayant acquis un statut iconique dans notre culture au point que les enfants se déguisent souvent en pain chaud et fromagé pour Halloween.</p>
  <p>Mais une étude récente montre que cet apéritif célébré pourrait être lié à une série de cas de rage apparus à travers le pays.</p>
</article>

Pour plus d'informations sur l'utilisation du plugin et les fonctionnalités qu'il inclut, lisez la documentation.

À quoi s'attendre à partir de maintenant

Ce qui suit est un tas d'absurdités que j'ai écrites pour tester le plugin lui-même. Cela inclut tous les éléments typographiques sensés auxquels j'ai pu penser, comme du texte en gras, des listes non ordonnées, des listes ordonnées, des blocs de code, des citations, et même de l'italique.

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

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

Maintenant, nous allons essayer un autre style de titre.

La typographie devrait être facile

Donc, voici un titre pour vous — avec un peu de chance, si nous avons bien fait notre travail, cela aura l'air assez raisonnable.

Quelqu'un de sage m'a dit un jour à propos de la typographie :

La typographie est assez importante si vous ne voulez pas que vos choses ressemblent à des déchets. Faites-la bien, alors ce ne sera pas mauvais.

Il est probablement important que les images aient également l'air correctes ici par défaut :

Contrairement à la croyance populaire, Lorem Ipsum n'est pas simplement un texte aléatoire. Il trouve 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 également l'air bien :

• 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.

Que se passe-t-il si nous empilons les titres ?

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

Parfois, vous avez des titres directement les uns sous les autres. 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 les uns des autres qu'un paragraphe suivi d'un titre.

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 regrettable car c'est assez ennuyeux d'obtenir les styles corrects.

  J'ai souvent deux ou trois paragraphes dans ces éléments de liste, 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 valoir qu'il ne faut tout 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 ait l'air réaliste. C'est pourquoi j'ai ajouté cet élément de liste supplémentaire pour avoir 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 cela aurait probablement été bien de n'utiliser que deux éléments, mais trois n'est certainement pas pire, et comme je semble ne pas avoir de mal à inventer des choses arbitraires à taper, autant l'inclure.

Après ce genre de liste, j'ai généralement une déclaration ou un paragraphe de clôture, car cela 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 de similaire s'ils veulent styliser leurs blocs de code, mais cela ne ferait pas de mal de les rendre corrects dès le départ, 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 suffisamment bon.

Qu'en est-il des 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 les faire, mais je suppose que puisque certains d'entre vous vont le faire, nous devons au moins faire en sorte que cela fonctionne.

1. Les listes imbriquées sont rarement une bonne idée.
   • Vous pourriez penser que vous êtes 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 également une mauvaise idée, gardez les choses aussi plates que possible.
   • Imbriquer des tonnes de dossiers dans votre code source n'est pas utile non plus.
2. Puisque nous avons besoin de plus d'éléments, en voici un autre.
   • Je ne suis pas sûr que nous nous embêterons à 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 la prison.
3. Deux éléments ne constituent pas vraiment une liste, trois c'est bien cependant.
   • Encore une fois, ne faites pas de listes imbriquées 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 embêter à styliser cela.

L'aspect le plus ennuyeux des listes en Markdown est que les éléments <li> ne reçoivent pas de balise enfant <p> sauf s'il y a plusieurs paragraphes dans l'élément de liste. Cela signifie que je dois également m'inquiéter de styliser 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 ne font qu'une ligne chacun

• Mais dans cet élément de liste de niveau supérieur, ils en auront.

  Cela 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, au fait.

  • Enfin, voici un autre élément de liste pour que cela ressemble davantage à une liste.

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

Et enfin une phrase pour clôturer 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 avons presque décidé de les rendre bleus, mais c'est tellement dépassé, alors nous avons opté pour un gris foncé, ça fait plus audacieux.

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

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

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

Même si c'est probablement une mauvaise idée, et historiquement j'ai eu du mal à le rendre beau. Ce "truc d'entourer les blocs de code avec 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 cela ne vaut absolument pas la folie que cela nécessiterait pour l'éviter.

Nous n'avons pas encore utilisé un h4

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

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

Nous devons encore penser aux titres empilés cependant.

Assurons-nous de ne pas gâcher cela 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 auront l'air étranges ou déséquilibrées s'il y a un titre trop près de la fin du document.

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

Markdown au style GitHub

J'ai également ajouté la prise en charge du Markdown au style GitHub 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 une balise a.

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