Textile und Markdown

Ein nicht unwesentliches Argument für die Wahl eines bestimmten Content-Management-Systems ist der Komfort für den Redakteur, der später die Website pflegen wird, auch wenn dieser Punkt von vielen Entwicklern oftmals zu wenig Beachtung findet.

Schaut man sich die unterschiedlichen Vorgehensweisen bei der Erstellung und Bearbeitung der Inhalte an, stößt man irgendwann unweigerlich auf die Gretchenfrage eines jeden CMS-Installateurs: »Wie hältst Du’s mit den visuellen Editoren?« Beinahe jedes moderne CMS bietet heutzutage die Möglichkeit, einen WYSIWYG-Editor in den Bearbeitungsmasken für Redakteure einzusetzen, die meisten kommen dabei standardmäßig mit einem voreingestellten TinyMCE daher. Ich habe mich schon immer gegen die visuellen Editoren gesträubt, aus diversen Gründen:

  • Das notwendige radikale Abrüsten der voreingestellten Funktionsfülle ist jedesmal ein hoher Zeitaufwand, den ich gerne vermeide.
  • In den meisten Fällen verhindern visuelle Editoren den Einsatz von eleganten, klassenbasierten Layoutkonstruktionen für den Inhaltsbereich.
  • Dynamische Funktionsaufrufe lassen sich meist nicht fehlerfrei integrieren.
  • Seltsame Eigendynamiken führen zu sehr eigenwilligem HTML-Code, selbst bei fachgerechter Handhabung.
  • Kunden werden kreativ und nutzen bestimmte Funktionen auf unorthodoxe Weise.

Zusammengefasst: Man schafft sich ein Monstrum an, welches auf völlig unnachvollziehbare Weise Dinge tut und andere Dinge verhindert. Man ist nicht mehr Herr seiner Inhaltspflege. Und da hat sich meines Erachtens auch in den letzten zwei bis drei Jahren nicht so viel getan. Man denkt immer, dass das inzwischen alles besser und cleaner und robuster ist. Stimmt aber nicht. Erst neulich hat mir TinyMCE üble Inline-Styles in den erzeugten Quellcode eingefügt, nur weil ich das CSS-Styling der Editiermaske an das Frontend angepasst hatte. So geht’s ja nicht!

Von daher setze ich eigentlich schon immer und bis heute auf die beiden populären HTML-Abstraktionen Textile bzw. Markdown, die mir im Allgemeinen gute Dienste erweisen. Doch welche der beiden Syntaxen ist besser? Und lässt sich das überhaupt dem Kunden vermitteln? Dazu einige Gedanken!

Zunächst einmal sind sich beide Schreibweisen ziemlich ähnlich: Normale Textabsätze werden als p-Element ausgezeichnet, ungeordnete Listen lassen sich mit Sternchen am Anfang jedes Listenpunktes erzeugen, und inline-Elemente wie <strong> und <em> sind auch weitestgehend parallel.

Doch interessanter sind natürlich die Unterschiede: Markdown ist deutlich »unschärfer« und ermöglicht oftmals mehrere Möglichkeiten, eine bestimmte Auszeichnung zu erreichen. Das kann Vor- und Nachteil zugleich sein. Immerhin führt es dazu, dass man Markdown-Texte sehr übersichtlich und »schön« gestalten kann, was ja auch die Hauptidee von John Gruber war, als er das System 2004 erfand.

Textile hingegen ist die präzisere und technischere Syntax und orientiert sich stärker an den tatsächlichen HTML-Elementen, was man bei den Headlines sehen kann, die mit h1. bis h6. gebildet werden. Textile bietet auch die Möglichkeit, Klassen und IDs für Headlines und Absätze zu definieren. (Leider klappt das nicht für div-Elemente oder ul-Elemente.) Einen großen Fauxpaus leistet sich Textile bei der Interpretation des <del>-Elementes: Es wird durch zwei einfache Bindestriche erzeugt, die am Anfang und am Ende der gewünschten Sequenz stehen. Wenn jedoch ein deutscher Text daherkommt mit einer zusammengesetzten Wort- oder Buchstaben-Konstruktion, kann das schon mal ins Auge gehen.

Doch auch Markdown ist nicht frei von Ungereimtheiten. So werden beispielsweise einfache Zeilenumbrüche komplett ignoriert – ledigiglich eine komplette Leerzeile vermag einen Absatz vom nächsten zu trennen. Will man jedoch einen echten Zeilenumbruch haben, muss man an das Ende der ersten Zeile zwei Leerzeichen schreiben, und danach in der nächsten Zeile wieder ansetzen. Sehr dämlich, denn natürlich sieht man die doppelten Leerzeichen nicht in der Editiermaske.

Man sollte noch erwähnen, dass es für Markdown eine erweiterte Version namens »Markdown Extra« gibt, die man definitiv der klassischen Version vorziehen sollte, denn sie ermöglicht – unter anderem – auch Definitionslisten und Tabellen. Letztere sind jedoch nicht für alle Fälle sinnvoll, denn sie müssen zwingend einen Tabellenkopf besitzen, was inhaltlich nicht immer möglich ist. Textile wiederum hat die deutlich flexiblere Tabellenfunktion, die jedoch auch unübersichtlicher und sehr schwer zu merken ist.

Beide Syntaxen lassen sich grundsätzlich mit reinem HTML mischen, wobei unter Markdown die Trennung ein wenig stabiler funktioniert – man kann über ein Pseudo-Attribut (markdown="1") festlegen, ob Inhalte, die innerhalb eines HTML-Elements geschrieben werden, ebenfalls geparst werden sollen oder nicht. Textile hantiert hier mit dem etwas wackeligen Prefix notextile., bei dem man sich nie ganz sicher ist, bei welchen zukünftigen Zeilen das noch gilt.

Ich überlege mir bei jedem Projekt aufs Neue, ob ich Markdown oder Textile einsetzen sollte. Entscheidend sind folgende Fragen:

  • Brauche ich Klassenattribute? (Textile wins!)
  • Brauche ich narrensichere Handhabung und Fehlertoleranz (Markdown wins!)
  • Brauche ich komplexere Tabellen? (Textile wins!)
  • Brauche ich öfters abgegrenzte Blöcke in reinem HTML? (Markdown wins!)

Kein klarer Sieger, und auch keine erschöpfende Antwort auf alle Fragen in der Praxis. Denn unabhängig von der Wahl der Basis-Syntax kommen meist noch individuelle Ergänzungen hinzu, die über eigene Suchen-und-Ersetzen-Plugins bestimmte Spezialfunktionen des Templates ansprechen. Ob diese Syntax-Ergänzungen dann vor oder nach der Basis-Syntax geparst werden, ist wieder eine Wissenschaft für sich …

Ich habe das Glück, dass meine bisherigen Kunden immer ganz gut mit eine der beiden Systeme klargekommen sind. Das ist natürlich nicht immer so. Ich habe jedoch die Erfahrung gemacht, dass insgesamt sehr viel weniger Stress entsteht, wenn man einfach einen ordentlichen Spickzettel bereithält und darauf hinweist, dass man mit einer solchen Abstraktion nichts kaputt machen kann und quasi automatisch gutaussehende strukturierte Texte verfassen kann. An die paar »kryptischen« Zeichen gewöhnen sich die Kunden schneller als man denkt, glaubt mir! Der saubere HTML-Output und die hohe Beherrschbarkeit der Technik machen den Mangel an Intuition und Möglichkeiten mehr als wett!