praegnanz.de büro für intervernetzte medien

Gerrit, 29.10.2009

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!

17 Kommentare

  1. Damian am 29. Oktober 2009 #

    Hallo Gerrit,

    ich weiß was du meinst, damit habe ich auch zu kämpfen gehabt.
    Speziell wenn es darum geht, die Kunden darauf zu sensibilisieren, den Text nicht eins zu eins von Word oder Konsorten in den TinyMCE zu kopieren, denn das bringt oftmals unschöne Strukturen in den Code, der Teilweise sogar die ganze Seite zerstückeln kann.
    Der Quellcode wird oftmals unübersichtlich, da der TinyMCE sehr gerne doppelt und dreifach die alten font-tags nutzt.
    Dummes System.

    Textile konnte ich bislang keinem andrehen, da ich bisher auch nur wenige kleine Projekte hatte und Textpattern auch noch nicht wirklich Produktiv nutzte. Ich kenne Textile und kommen damit als Tekki natürlich sehr gut klar und finde es von der Form her wesentlich übersichtlicher als das TinyMCE und führt definitiv zu weniger Fehlern (bei mir jedenfalls).

    Grüße Damian

  2. Oliver am 29. Oktober 2009 #

    Die Lösung ist doch ganz einfach:

    Textile + markItUp!

    LG
    Oliver

  3. Meerblickzimmer am 29. Oktober 2009 #

    @Damian: Ich glaub das Problem ist Word – nicht TinyMCE. Gibt ja auch extra den netten »Text von Word einfügen«-Button in TinyMCE.

    @Geritt: TinyMCE ist – zumindest was die Anzahl & Position der Buttons betrifft – in wenigen Minuten konfiguriert. Das ist doch einfach und funktioniert recht gut. Was problematischer ist, wenn man Versucht TinyMCE grundsätzlich zu stylen (Form & Farbe) oder gar eigene Plugins entwickelt. Aber die Buttons & damit Funktionen auszuschalten, geht wirklich simple.

    Grundsätzlich halte ich TinyMCE für ganz gut und Kunden kommen damit auch gut zurecht.

  4. Dieter am 29. Oktober 2009 #

    Bin ich froh, dass ich keine Kunden betreuen muss.
    Ich verwende einfach WorPress mit dem mitgelieferten TinyMCE und gut ist. Naja, meistens.

    Ich gebe zu, manchmal ärgere ich mich auch über die eine oder andere eigenwillige Codeveränderung im WYSIWYG-Modus.

  5. jo jmatic am 29. Oktober 2009 #

    Ich nutze schon seit langer Zeit Textile in Verbindung mit Textmate (auf’m Mac) zum bloggen. Das klappt wunderbar.

    Das »Bindestrich«-Problem hatte ich auch schon. Ich meine eine Lösung gehabt zu haben, erinnere mich aber nicht mehr genau. Na toll … Schwester, die Pillen bitte!

    Es könnte aber folgendermaßen klappen:
    Löst man das Problem evtl. dadurch, dass man, z.B. bei diesem Ausdruck: »Wort– oder Buchstaben–Konstruktion», am Anfang und am Ende (zwecks späterer <del>-Erzeugung) den normalen Bindestrich nutzt, und im Ausdruck selber den langen Bindestrich [ALT-Bindestrich]?

    Also, in Textmate funktionierte das eben, beim Umwandeln in html.

    Probleme habe ich manchmal bei Links (in Textile) die am Ende z.B. ein # oder ein ? haben. Die werden bei der Umwandlung in html (in Textmate) regelmäßig aus dem Link geschossen. Das ist aber nicht schlimm, wenn man denn dran denkt.

    Nu ja, wie auch immer, ich kann jedenfalls Textile in Verbindung mit Textmate nur empfehlen.

  6. Gerrit am 29. Oktober 2009 #

    Links kann man in Textile stabiler machen, indem man sie komplett mit eckigen Klammern umschließt: [»Linktext« :http://link.de]

  7. Schepp am 29. Oktober 2009 #

    Ich schließe mich @Meerblickzimmer darin an, dass es bei TinyMCE darauf ankommt, ihn korrekt zu konfigurieren. Ist das einmal erledigt, kann man die Wunschkonfiguration ja immer wieder zu neuen Projekten mitnehmen. Anomalien der Art wie Du sie schilderst hatte ich nie, und auch das ganze Word-Geschrabbels kann man per Autocleanup noch im Tiny rauswerfen (erlaubte, nicht erlaubte Tags/Attribute).

    Folgendes noch ergänzend:

    Hauptüberschriften und Anreisser stelle ich dem Redakteur nie innerhalb von Tiny zur Verfügung, sondern stelle dafür eigens gestylte (vertikal wachsende) Textareas zur Verfügung. Da kann ich sie auch im Backend schneller packen und kann automatisch Titel und Metadaten daraus generieren.

    Subheadlines und spezielle Klassen bekommt der Redakteur bei mir nur zu sehen, wenn es sich gar nicht vermeiden lässt. Statt dessen empfiehlt sich folgendes:

    Ich blende einen sonst nicht brauchbaren Knopf à la <stroke> in der Toolbar ein, dem ich durch Bildtausch ein anderes Icon verpasse, sagen wir mal eine Icon für eine Zwischenüberschrift.
    Das <stroke> wird dann im TinyMCE-content.css wie eine Zwischenüberschrift umgestyled, und später im Backend gegen <h3> austauscht. Die umgekehrte Ersetzung erfolgt vor dem Bearbeiten bestehender Artikel.

  8. Hauke Rehfeld am 29. Oktober 2009 #

    Die Syntax von texy! ist für mich immer noch am natürlichsten, irgendwie ist das fast genau, was ich mir selber in ein Textfile schreiben würde. Hier ein Beispiel für ein komplettes File und ungefähr so sieht’s dann aus

    Ich habe das schon für diverse Uni-Mitschriften und Files, sowie meine Website eingesetzt. Es gibt ein paar hakelige Stellen in der Syntax (z.B. Liste in einer Definition List), und die Doku ist leider schlecht, aber ich bin größtenteils überzeugt. Der Code ist auch annehmbar, bzw. großartig im Vergleich zu den meisten anderen PHP Libraries.

  9. Markus Schlegel am 29. Oktober 2009 #

    Ich benutze auch Textile und es treten dann doch recht häufig Kollisionen auf, vor allem, wenn das Dokument ein etwas akstraktes Thema behandelt. Und dann im Kopf zu haben, welche Umwege es noch gibt, will ich keinem Unversierten zutrauen müssen.

    Mein favorisiertes Prinzip für Markup-Editoren wäre das, welches Lyx ganz gut drauf hat. What you see is what you mean, ist zwar auch nicht bis in’s letzte Detail durchgesetzt (es heißt zwar »Hervorgehoben«, aber es heißt auch »Fettschrift«), aber das kommt meinem Wunsch schon recht nahe.

    Schön ist vor allem, dass der User Entscheidungen treffen muss (Beende ich den Absatz jetzt oder nicht?) und dabei möglichst unfrei ist, d.h. möglichst wenige Entscheidungsmöglichkeiten zur Verfügung hat. Diese Eingeschränkheit ist beim ersten Benutzen sicher beengend, ist aber das einzig Sinnvolle. Das ganze übrigens ohne jegliche Inline-Kryptik

    Wenn man das in’s Web bringen würde und es dann von mir aus noch vom Feeling her an den Powerpoint-Struktureditor angleicht … was will man bitte mehr?

    Ich hatte das auch schon einmal versucht; scheiterte aber wie so vieles am abrupten Ferienende ;)

  10. David am 29. Oktober 2009 #

    Ich komme bislang mit Textile wunderbar klar. Das einzige, was mir wirklich fehlt, ist die Möglichkeit von Definitionslisten. Und die setze ich gerne und häufig ein. :-/

  11. Nicolai Schwarz am 30. Oktober 2009 #

    Das funktioniert natürlich nur, wenn Kunden nicht von sich aus einen WYSIWYG-Editor haben wollen. Dann kommt man nicht drum herum, Ihnen auch einen zu geben.

    Meine Lösung: Drupal + (TinyMCE oder FCKEditor) + HTML Purifier

    Die Editoren lassen sich schon so einrichten, dass der Kunde nicht alles machen darf. Dann werden auch keine font-Elemente genutzt oder Inline-Styles vergeben. Import aus Word ist immer ein Problem, auch wenn Tiny sein möglichstes tut, um den Krempel sinnvoll zu importieren.

    Mein neuer Liebling ist aber der HTML Purifier, der den Code, den Kunden eingeben/erzeugen, bei der Ausgabe noch einmal durchgeht. Schönes Teil.

    Natürlich kann auch das nicht verhindert, dass ein Kunde eine Zwischenüberschrift einfach nur fettet oder eine Liste durch vorangestellt Minuszeichen erzeugt. Semantisch haben Textile und MarkUp da in der Regel die Nase vorn.

  12. Stefan am 1. November 2009 #

    Ich persönlich habe jahrelang Markdown benutzt, es ist schnell und elegant, aber wie Gerrit erwähnt etwas stark begrenzt. Selbst Erweiterungen wie Markdown Extra können da nur begrenzt aushelfen.

    Nicht zu vernachlässigen ist aber auch die Rendergeschwindigkeit. In eigenen Messungen mit einem System rangiert Textile mit 3-4 Mal mehr Zeit hinter Markdown.

    Seit kurzem beschäftige ich mich mit einer echten Alternative, die aus dem Dokumentationsbereich von Python kommt: reStructuredText. Die Sprache ist simple für Grundlagen, kann aber so gut wie alles, was sich ein typophiler Designer wünschen kann. Ob Pull-Quotes, Gedichte, Code, Fußnoten, komplexe Tabellen, Randnotizen: ReStructuredText hat sie alle. Und ist beliebig zu erweitern. Es ist sogar möglich ein reST-Dokument direkt in LaTeX zu rendern oder ein PDF daraus zu erzeugen. Von der Rendergeschwindigkeit agiert reST hinter Markdown, aber noch weit vor Textile. Was besonders schön ist: Texte, die in reStructuredText geschrieben sind, kann man tatsächlich lesen, selbst in purer Textform.

    Bei Relaunch meiner Website werde ich auf reST für Artikel zurückgreifen, für Kommentare, wegen der Einfachheit auf Markdown.

  13. Su-Mu am 2. November 2009 #

    Apropos Links: Wie wäre es denn mit diesem genialen Plugin?

  14. Stefan am 10. November 2009 #

    Interessant ist evtl auch noch der Hybrid-Weg: MarkitUp , das es auch als Addon für Redaxo gibt. Damit bekommt man gleichzeitig Komfort und validen Code.

  15. David Hellmann am 22. November 2009 #

    Ich nutze nur HTML und versuche das auch so weiterzugeben. In Wordpress via Plugin »Quicktags« ein paar Buttons mit eingebaut die man gebrauchen könnte. Der rest ist doch meisten eh nur der Standardkram:

    Headlines
    Absätze
    Links
    Bilder
    Textformatierung

    Die paar HTML Bausteine kann man sich schon merken wenn man öfters als einmal im Jahr Content auf der Seite einpflegt. Ich mag die ganzen WYSIWYG Editoren einfach nicht.

    Und ich weiß immer was hinten raus kommt wenn ich das HTML selber da rein bastle.

  16. Jörg am 20. Januar 2011 #

    Ich mache das anders:

    Ich speichere grundsätzlich HTML.

    Zum Bearbeiten suche ich mir dann raus: will ich WYSIWYG, dann nehme ich, was mein Desktop mir bietet und arbeite via WebDAV; will ich ein wenig ändern und alles behalten, was HTML kann, dann ändere ich den reinen Quellcode; will ich einfach arbeiten, dann wähle ich die Syntax, die paßt.

    Mein einziges Problem beim raussuchen, welche Syntax paßt: nicht alle Konvertierungen erlauben »Rundreisen«,also b2a(a2b(A)) = A.

  17. Torsten am 6. Oktober 2015 #

    Ich würde mich ja ganz gern mal näher mit Textile befassen, ich kenne es von Textpattern, das ich vor Jahren mal als Blogsystem benutzt habe (das mich aber nicht dauerhaft überzeugen konnte).

    Die Sache ist nur die: Es gibt fürs Windows-Betriebssystem so gut wie keine Textile-Editoren, zumindest habe ich nur einen einzigen gefunden: Write! (https://wri.tt/). Die Pro-Version soll allerdings nur per Subscription erhältlich sein, und das kommt für mich nicht in Frage.

    Markdown-Editoren hingegen gibt es fast wie Sand am Meer, und darunter ein paar richtig gute. Ich habe halt ganz gerne eine bebilderte Menüleiste, weil ich doch schon mal bestimmte, nicht so häufig verwendete Formatierungsanweisungen vergesse und dann froh bin, mal eben mit der Maus auf einen Button drücken zu können. Mein Liebling ist MarkdownPad 2.

    Content-Management-Systeme, die Markdown-Editoren von Haus aus anbieten, werden immer mehr. Wie einige andere Kommentatoren, suche auch ich immer wieder nach Möglichkeiten, irgendwie zu verhindern, dass Kunden furchtbare Dinge tun; aber gleichzeitig sollen sie ja auf einfache Weise ihre Inhalte eingeben können. Doch auch mit der Markdown-Syntax kommen manche nicht zurecht, man denke nur an die zwei Leerzeichen am Zeilenende für einen Zeilenumbruch …

    Es bleibt schwierig.

    Gruß
    Torsten

Kommentar schreiben

Nutzt Textile zum Strukturieren eures Textes.
SEO-Beiträge werden gelöscht, auch bei thematisch passendem Spam.