Stilrichtlinie

Bis jetzt war es eine mühsame Aufgabe, einen Artikel, ein Dokument oder einen Blogbeitrag mit Tailwind zu gestalten, die ein gutes Auge für Typografie und viel komplexes benutzerdefiniertes CSS erforderte.

Standardmäßig entfernt Tailwind alle Standard-Browser-Stile von Absätzen, Überschriften, Listen und mehr. Das ist wirklich nützlich für den Aufbau von Anwendungs-UIs, da man weniger Zeit damit verbringt, Benutzeragenten-Stile rückgängig zu machen. Aber wenn man wirklich nur versucht, Inhalte zu gestalten, die aus einem Rich-Text-Editor in einem CMS oder einer Markdown-Datei stammen, kann das überraschend und unintuitiv sein.

Wir erhalten tatsächlich viele Beschwerden darüber, wobei Leute uns regelmäßig Dinge fragen wie:

Warum entfernt Tailwind die Standardstile meiner h1-Elemente? Wie deaktiviere ich das? Was meinst du damit, dass ich auch alle anderen Basisstile verliere? Wir hören euch, aber wir sind nicht überzeugt, dass das einfache Deaktivieren unserer Basisstile das ist, was ihr wirklich wollt. Ihr wollt nicht jedes Mal nervige Abstände entfernen müssen, wenn ihr ein p-Element in einem Teil eurer Dashboard-UI verwendet. Und ich bezweifle, dass ihr wirklich wollt, dass eure Blogbeiträge die Benutzeragenten-Stile verwenden — ihr wollt, dass sie großartig aussehen, nicht schrecklich.

Das @tailwindcss/typography Plugin ist unser Versuch, euch das zu geben, was ihr wirklich wollt, ohne die Nachteile von etwas Dummem wie dem Deaktivieren unserer Basisstile.

Es fügt eine neue prose-Klasse hinzu, die ihr auf jeden Block von Vanilla-HTML-Inhalten anwenden könnt, um ihn in ein schönes, gut formatiertes Dokument zu verwandeln:

<article class="prose">
  <h1>Knoblauchbrot mit Käse: Was die Wissenschaft uns sagt</h1>
  <p>Seit Jahren preisen Eltern die gesundheitlichen Vorteile des Verzehrs von Knoblauchbrot mit Käse ihren Kindern an, wobei das Essen einen solchen ikonischen Status in unserer Kultur erlangt hat, dass Kinder sich oft als warmes, käsiges Brot zu Halloween verkleiden.</p>
  <p>Aber eine kürzlich durchgeführte Studie zeigt, dass die gefeierte Vorspeise mit einer Reihe von Tollwutfällen im ganzen Land in Verbindung gebracht werden könnte.</p>
</article>

Für weitere Informationen darüber, wie man das Plugin verwendet und welche Funktionen es enthält, lest die Dokumentation.

Was ihr von hier an erwarten könnt

Was folgt, ist nur eine Menge absoluter Unsinn, den ich geschrieben habe, um das Plugin selbst zu testen. Es enthält jedes sinnvolle typografische Element, das mir einfällt, wie fetter Text, ungeordnete Listen, geordnete Listen, Codeblöcke, Blockzitate, und sogar Kursivschrift.

Es ist wichtig, all diese Anwendungsfälle abzudecken, aus ein paar Gründen:

1. Wir wollen, dass alles von Anfang an gut aussieht.
2. Wirklich nur der erste Grund, das ist der ganze Sinn des Plugins.
3. Hier ist ein dritter vorgetäuschter Grund, obwohl eine Liste mit drei Elementen realistischer aussieht als eine Liste mit zwei Elementen.

Jetzt probieren wir einen anderen Überschriftenstil aus.

Typografie sollte einfach sein

Das ist also eine Überschrift für euch — mit etwas Glück sieht das, wenn wir unsere Arbeit richtig gemacht haben, ziemlich vernünftig aus.

Etwas, das mir eine weise Person einmal über Typografie gesagt hat:

Typografie ist ziemlich wichtig, wenn du nicht willst, dass deine Sachen wie Müll aussehen. Mach es gut, dann wird es nicht schlecht sein.

Es ist wahrscheinlich auch wichtig, dass Bilder hier standardmäßig gut aussehen:

Entgegen der landläufigen Meinung ist Lorem Ipsum nicht einfach nur zufälliger Text. Es hat seine Wurzeln in einem Stück klassischer lateinischer Literatur aus dem Jahr 45 v. Chr., was es über 2000 Jahre alt macht.

Jetzt zeige ich euch ein Beispiel für eine ungeordnete Liste, um sicherzustellen, dass auch das gut aussieht:

• Hier ist also das erste Element in dieser Liste.
• In diesem Beispiel halten wir die Elemente kurz.
• Später verwenden wir längere, komplexere Listenelemente.

Und das ist das Ende dieses Abschnitts.

Was, wenn wir Überschriften stapeln?

Wir sollten sicherstellen, dass das auch gut aussieht.

Manchmal hat man Überschriften direkt untereinander. In diesen Fällen muss man oft den oberen Rand der zweiten Überschrift rückgängig machen, da es normalerweise besser aussieht, wenn die Überschriften näher beieinander sind, als wenn ein Absatz von einer Überschrift gefolgt wird.

Wenn eine Überschrift nach einem Absatz kommt …

Wenn eine Überschrift nach einem Absatz kommt, brauchen wir etwas mehr Platz, wie ich oben bereits erwähnt habe. Jetzt sehen wir uns an, wie eine komplexere Liste aussehen würde.

• Ich mache oft diese Sache, bei der Listenelemente Überschriften haben.

  Aus irgendeinem Grund finde ich, dass das cool aussieht, was bedauerlich ist, weil es ziemlich nervig ist, die Stile richtig hinzubekommen.

  Ich habe oft zwei oder drei Absätze in diesen Listenelementen, also besteht die Herausforderung darin, den Abstand zwischen den Absätzen, der Listenüberschrift und den separaten Listenelementen sinnvoll zu gestalten. Ziemlich schwierig, ehrlich gesagt, man könnte stark argumentieren, dass man einfach nicht so schreiben sollte.

• Da dies eine Liste ist, brauche ich mindestens zwei Elemente.

  Ich habe bereits im vorherigen Listenelement erklärt, was ich tue, aber eine Liste wäre keine Liste, wenn sie nur ein Element hätte, und wir wollen wirklich, dass das realistisch aussieht. Deshalb habe ich dieses zweite Listenelement hinzugefügt, damit ich tatsächlich etwas habe, das ich beim Schreiben der Stile betrachten kann.

• Es ist auch keine schlechte Idee, ein drittes Element hinzuzufügen.

  Ich denke, es wäre wahrscheinlich in Ordnung gewesen, nur zwei Elemente zu verwenden, aber drei sind definitiv nicht schlechter, und da es mir anscheinend leicht fällt, willkürliche Dinge zu tippen, kann ich es genauso gut hinzufügen.

Nach einer solchen Liste habe ich normalerweise eine abschließende Aussage oder einen Absatz, weil es irgendwie seltsam aussieht, direkt zu einer Überschrift zu springen.

Code sollte standardmäßig gut aussehen.

Ich denke, die meisten Leute werden highlight.js oder Prism oder etwas Ähnliches verwenden, wenn sie ihre Codeblöcke gestalten möchten, aber es schadet nicht, sie okay aussehen zu lassen, auch ohne Syntaxhervorhebung.

Hier ist, wie eine Standard-tailwind.config.js-Datei zum Zeitpunkt des Schreibens aussieht:

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

Hoffentlich sieht das für euch gut genug aus.

Was ist mit verschachtelten Listen?

Verschachtelte Listen sehen im Grunde immer schlecht aus, weshalb Editoren wie Medium euch nicht einmal erlauben, sie zu erstellen, aber ich schätze, da einige von euch Spaßvögeln das tun werden, müssen wir zumindest dafür sorgen, dass es funktioniert.

1. Verschachtelte Listen sind selten eine gute Idee.
   • Ihr denkt vielleicht, ihr seid wirklich "organisiert" oder so, aber ihr schafft nur eine hässliche Form auf dem Bildschirm, die schwer zu lesen ist.
   • Verschachtelte Navigation in UIs ist auch keine gute Idee, haltet die Dinge so flach wie möglich.
   • Das Verschachteln von Ordnern in eurem Quellcode ist ebenfalls nicht hilfreich.
2. Da wir mehr Elemente brauchen, hier ist ein weiteres.
   • Ich bin mir nicht sicher, ob wir uns die Mühe machen werden, mehr als zwei Ebenen tief zu gestalten.
   • Zwei sind schon zu viel, drei sind garantiert eine schlechte Idee.
   • Wenn ihr vier Ebenen tief verschachtelt, gehört ihr ins Gefängnis.
3. Zwei Elemente sind keine echte Liste, drei sind aber gut.
   • Bitte verschachtelt keine Listen, wenn ihr wollt, dass Leute euren Inhalt tatsächlich lesen.
   • Niemand will sich das ansehen.
   • Es ärgert mich, dass wir uns überhaupt die Mühe machen müssen, das zu gestalten.

Das Nervigste an Listen in Markdown ist, dass <li>-Elemente kein untergeordnetes <p>-Tag erhalten, es sei denn, es gibt mehrere Absätze im Listenelement. Das bedeutet, dass ich mir auch Gedanken über die Gestaltung dieser nervigen Situation machen muss.

• Zum Beispiel hier eine weitere verschachtelte Liste.

  Aber diesmal mit einem zweiten Absatz.

  • Diese Listenelemente haben keine <p>-Tags
  • Weil sie jeweils nur eine Zeile haben

• Aber in diesem zweiten Listenelement der obersten Ebene schon.

  Das ist besonders ärgerlich wegen des Abstands in diesem Absatz.

  • Wie ihr hier sehen könnt, weil ich eine zweite Zeile hinzugefügt habe, hat dieses Listenelement jetzt ein <p>-Tag.

    Das ist übrigens die zweite Zeile, von der ich spreche.

  • Schließlich hier ein weiteres Listenelement, damit es mehr wie eine Liste aussieht.

• Ein abschließendes Listenelement, aber ohne verschachtelte Liste, weil warum nicht?

Und schließlich ein Satz, um diesen Abschnitt abzuschließen.

Es gibt andere Elemente, die wir gestalten müssen

Ich hätte fast vergessen, Links zu erwähnen, wie diesen Link zur Tailwind CSS-Website. Wir hätten sie fast blau gemacht, aber das ist so gestern, also haben wir uns für Dunkelgrau entschieden, fühlt sich kantiger an.

Wir haben sogar Tabellenstile hinzugefügt, schaut mal:

Wir müssen auch sicherstellen, dass Inline-Code gut aussieht, wie wenn ich über <span>-Elemente sprechen oder euch die guten Nachrichten über @tailwindcss/typography erzählen möchte.

Manchmal verwende ich sogar code in Überschriften

Auch wenn es wahrscheinlich keine gute Idee ist und ich historisch gesehen Schwierigkeiten hatte, es gut aussehen zu lassen. Dieser "umwickle die Codeblöcke mit Backticks"-Trick funktioniert aber wirklich ziemlich gut.

Eine andere Sache, die ich in der Vergangenheit gemacht habe, ist, ein code-Tag in einen Link einzufügen, wie wenn ich euch über das tailwindcss/docs Repository erzählen möchte. Ich mag es nicht, dass es eine Unterstreichung unter den Backticks gibt, aber es ist absolut nicht den Wahnsinn wert, den es erfordern würde, das zu vermeiden.

Wir haben noch kein h4 verwendet

Aber jetzt haben wir. Bitte verwendet keine h5 oder h6 in eurem Inhalt, Medium unterstützt aus gutem Grund nur zwei Überschriftenebenen, ihr Tiere. Ich habe ernsthaft darüber nachgedacht, ein before-Pseudo-Element zu verwenden, um euch anzuschreien, wenn ihr ein h5 oder h6 verwendet.

Wir gestalten sie überhaupt nicht standardmäßig, weil h4-Elemente bereits so klein sind, dass sie die gleiche Größe wie der Fließtext haben. Was sollen wir mit einem h5 machen, es kleiner als den Fließtext machen? Nein, danke.

Wir müssen aber immer noch über gestapelte Überschriften nachdenken.

Stellen wir sicher, dass wir das mit h4-Elementen auch nicht vermasseln.

Puh, mit etwas Glück haben wir die Überschriften über diesem Text gestaltet und sie sehen ziemlich gut aus.

Fügen wir hier einen abschließenden Absatz hinzu, damit die Dinge mit einem anständig großen Textblock enden. Ich kann nicht erklären, warum ich möchte, dass die Dinge so enden, aber ich muss annehmen, dass es daran liegt, dass ich denke, dass die Dinge seltsam oder unausgewogen aussehen, wenn eine Überschrift zu nah am Ende des Dokuments ist.

Was ich hier geschrieben habe, ist wahrscheinlich lang genug, aber das Hinzufügen dieses letzten Satzes kann nicht schaden.

GitHub Flavored Markdown

Ich habe auch Unterstützung für GitHub Flavored Markdown mit remark-gfm hinzugefügt.

Mit remark-gfm erhalten wir ein paar zusätzliche Funktionen in unserem Markdown. Beispiel: Autolink-Literale.

Ein Link wie www.example.com oder https://example.com würde automatisch in ein a-Tag umgewandelt.

Das funktioniert auch für E-Mail-Links: contact@example.com.