Markdown übernommen! Warum es das digitale Schreiben revolutioniert hat

• Markdown wurde entwickelt, um Klartext einfach lesbar und schreibbar zu machen. Markdown bildet eine flexible Grundlage für die Formatierung von Text in verschiedenen Formaten wie HTML, PDF und DOC. Markdown basiert auf informellen Konventionen und verbreiteten Schreibroutinen, was seinen Erfolg förderte. Es gibt Mehrdeutigkeiten in der Markdown-Syntax, die unterschiedliche Implementierungen und Interpretationen ermöglichen. CommonMark versucht, diese Mehrdeutigkeiten zu beseitigen, wird jedoch nicht als der wahre Geist von Markdown angesehen.

Am Anfang war das Wort, und das Wort war Klartext, und das Wort war Klartext, weil Klartext der Weg war. Es war gut. Am sechsten Tag – ich springe hier ein bisschen voraus – wurde das Internet geboren. Das Wort musste nun in HTML umgeschrieben werden. Jetzt gab es zwei Worte. Es war nicht gut. Am achten Tag, nach einer kurzen Pause, wurde Markdown geboren. Markdown machte es möglich, das Wort als HTML im Web, als PDF in der Bibliothek, als LaTeX im Verlag und sogar als Microsoft Word DOC im Büro darzustellen – alles aus demselben Klartext generiert. Die Menschen erkannten, dass in dieser Form das Wort flexibler war. Es war gut. Das Internet jubelte und setzte Markdown überall ein.

Die Geburt von Markdown

Hier begannen die wirklichen Probleme. Heute ist Markdown möglicherweise das allgegenwärtigste Stück Code im Web. Unterstützung für Markdown ist in nahezu jedem Online-Textfeld eingebaut, auf das Sie wahrscheinlich stoßen werden, und es gibt eine ganze Wirtschaft von mobilen Schreib- und Notiz-Apps, die darauf aufbauen. Markdown ist nicht nur ein Stück Software. Es ist auch eine Auszeichnungssprache – sie wird verwendet, um Klartext zu formatieren, der dann beispielsweise im Internet so erscheint, wie Sie es möchten. Laut dem Erfinder John Gruber wurde die Markup-Sprache Markdown entwickelt, um “so leicht lesbar und schreibbar wie möglich” zu sein. Ein Markdown-formatiertes Dokument sollte “wie es ist, als Klartext veröffentlicht werden können, ohne dass es so aussieht, als wäre es mit Tags oder Formatierungsanweisungen versehen”.

Dies, so meine ich, ist der Eckpfeiler von Markdowns Erfolg (und warum verwandte Projekte aus dieser Zeit wie reStructuredText und Setext weitgehend unbekannt geblieben sind): Es baute auf den informellen Konventionen auf, die die Menschen tatsächlich verwendeten. Markdown nahm gewöhnliche Eigenheiten des Schreibens von Klartext-E-Mails oder Forenbeiträgen – wie das Einfassen eines Wortes mit Sternchen, um es *zu betonen* – und erweiterte diese Formatierungsgewohnheiten. Es kam nicht daher und erklärte eine völlig neue Syntax und bat die Menschen, diese anzunehmen.

Die Philosophie hinter Markdown

Natürlich gibt es einige wichtige Annahmen hinter Markdown. Die größte ist, dass das ideale kanonische Format zur langfristigen Speicherung von Daten Klartext ist. Für jeden Programmierer ist dies offensichtlich. Code ist Klartext. Menschen schreiben in Text – unter Verwendung von Texteditoren, von denen einige über 40 Jahre alt sind – und wir haben sogar ganze Betriebssysteme (Unix) erstellt, die auf der Idee basieren, dass das Dateisystem ein Baum von Klartextdateien ist. Klartext ist das Alpha und das Omega digitaler Dateien.

Ich begegnete Markdown zum ersten Mal, als Gruber gegen Ende 2004 etwas darüber in der BBEdit-Mailingliste veröffentlichte. (Zu dieser Zeit fanden die meisten wertvollen Diskussionen auf BBSes oder per E-Mail statt.) Wie die meisten Menschen konnte ich Markdown an einem Nachmittag auswendig lernen, da wir bereits die Hälfte davon verwendeten.

Ich mochte Markdown so sehr, dass ich den Parser nahm und ihn anpasste, um LaTeX auszugeben, ein System zur Satzherstellung, das ich dann in PDFs konvertieren und drucken konnte. Ich hatte nie eine Zeile Perl geschrieben (die Sprache, in der Gruber Markdown schrieb), und ich hatte auch nie versucht, einen regulären Ausdruck zu erstellen (was den Großteil des Codes im Markdown-Parser ausmacht), aber der Code war da draußen, warum also nicht versuchen? Es funktionierte.

Mehrdeutigkeiten und Lösungen

Markdown wurde zu einem zentralen Bestandteil meiner Schreibweise. Die Einfachheit und Flexibilität bedeuteten, dass ich den Traum vom einmaligen Schreiben und überall Ausführen leben konnte. Dies führte jedoch zu einigen Mehrdeutigkeiten. Gruber würde wahrscheinlich sagen, dass dies Absicht ist. Sein Schwerpunkt in der gesamten Markdown-Dokumentation liegt auf der Syntax von Markdown, nicht – sagen wir – auf dem resultierenden HTML. Sein Perl-Skript unterstützt beispielsweise keine HTML-Klassennamen oder IDs, sodass Sie diese nicht zum generierten HTML hinzufügen können. Nach der Logik des ursprünglichen Markdown-Skripts müssen Sie, wenn Sie die vollständige Kontrolle über die HTML-Ausgabe haben möchten, HTML schreiben.

Diese Situation ist großartig für Markdown-Benutzer: nämlich für Autoren. Für Programmierer ist es weniger großartig. Tatsächlich macht es sie verrückt. Programmierer mögen keine Mehrdeutigkeit. Es widerspricht so vielem, worum es beim Programmieren geht. Als Autor, der Markdown verwendet, liebe ich es, dass ich die Version auswählen kann, die am besten zu meinen Bedürfnissen passt. Als Programmierer hasse ich es, dass ich, wenn ich etwas baue, dieselbe Entscheidung treffen muss, die dann alle Personen betrifft, die mein Endprodukt verwenden. Vielleicht habe ich keine bestimmte Erweiterung unterstützt, die sie erwartet haben, weil sie immer denselben Markdown-Parser verwendet haben und davon ausgehen, dass diese Funktion verfügbar ist.

Wenn dies nicht schon schlimm genug wäre, gibt es auch einige Mehrdeutigkeiten in der Syntax. Zum Beispiel werden Sternchen für Kursivschrift verwendet, wenn sie einzeln sind (*wie dies*) und fett, wenn sie verdoppelt sind (**wie dies**). Soweit, so gut. Aber was sollte passieren, wenn Sie **wie* dies** schreiben? Sollte dies wie* dies gerendert werden? Oder vielleicht wie dies*? Es gibt keine Möglichkeit, dies zu wissen; derjenige, der den Parser schreibt, muss diese Entscheidung treffen.

Markdown und CommonMark

Anders als die meisten extrem erfolgreichen Stücke Code, wird Markdown nicht öffentlich auf der Code-Sharing-Website des Tages gehostet. Es hat nicht Hunderte von Menschen, die dazu beitragen, und das letzte Mal, dass das ursprüngliche Perl-Skript aktualisiert wurde, war 2004. Auch das stößt Programmierern sauer auf. Wir sind ein klüngelhaftes Völkchen; Dinge außerhalb des Klüngels sehen wir mit Argwohn.

Vor etwa einem Jahrzehnt gab es einen Versuch, die Mehrdeutigkeiten in Markdown zu beseitigen und es mit Programmiergrundsätzen in Einklang zu bringen. Einige Programmierer kamen zusammen und schufen CommonMark, das die Entscheidungen trifft, die das ursprüngliche Markdown-Skript nicht trifft, und eine Art “Einzig richtige Methode” vorschlägt. CommonMark bietet Komfort. Es ist auf Github. Es hat ein Diskussionsforum. Es scheint ein aktives Projekt zu sein. Obwohl ich persönlich CommonMark nie in ein Projekt integriert habe, sind es seine Parser, die Ihr Markdown beispielsweise bei Stack Overflow, Github und Reddit in HTML umwandeln. (Um die Sternchen-Mehrdeutigkeit zu beseitigen, schlug es vor, Unterstrich für Kursivschrift und Sternchen für Fett zu verwenden.) Die Entwickler hinter CommonMark halten es vermutlich für einen Erfolg.

Aber es ist nicht Markdown. Nicht namentlich und, ich würde behaupten, nicht im Geist.

Zur Zeit der CommonMark-Bemühungen sagte mir der Softwareentwickler Dave Winer etwas, das ich immer noch denke: Markdown gehört allen, die es nutzen. Das ist buchstäblich wahr wegen der Lizenz. Aber es erinnerte mich auch an den eigentlichen Zweck freier Software. Wir alle haben ein Mitspracherecht: durch die Nutzung, durch Anpassung, sogar durch Forken.

Ob Gruber das so beabsichtigt hat oder nicht, Markdown gehört tatsächlich allen, und es gibt keinen Standard. Ich benutze eine sehr alte Version von Markdown für Python. Gruber verwendet vermutlich immer noch sein Perl-Skript. Andere Menschen verwenden andere Versionen. Es ist chaotisch. Es ist mehrdeutig. Es ist menschlich.

Und dies ist letztlich der Weg.