Das leidige Backend-Editor-Problem

Immer wieder kommt es zur Diskussion um den richtigen Backend-Texteditor für Blogs, CMSe und sonstige Webanwendungen. Ich selber halte XHTML-Code eigentlich für eine brauchbare Auszeichnungssprache und schreibe deshalb meine Blogeinträge auch direkt in XHTML, sogar die Absätze schreibe ich momentan noch selber. Dafür habe ich die volle Kontrolle über den Code und das ist mir wichtiger als der Verlust an Komfort.

Wie ist es aber, wenn weitere Autoren ins Spiel kommen? Bei unserer Typo3-Installation am Fachbereich haben wir lange diskutiert mit dem Schluss, dass wir den Professoren, HiWis und sonstigen Mitarbeitern so etwas nicht zumuten können. Wir können auch nicht voraussetzen, dass die auch nur halbwegs technisch in der Lage sind, fehlerfreien XHTML- bzw. Typo3-Code zu produzieren, auch wenn es sich nur um Links in der Form <link 125>Linktext</link> und eventuell eine Auszeichnung in fett handelt (viel mehr lässt unser Corporate Design im Text gar nicht zu). Alleine die benötigte Seiten-ID herauszufinden ist schon nicht trivial. Was also tun? Wir setzen notgedrungen auf den in Typo3 eingebauten RTEHTMLArea, der aber aus Code-Sicht mehr als fraglich ist. Unbefriedigend für mich, den Redakteuren aber weitgehend egal.

Aber die ideale Lösung? Eine Lösung, die auch mich ruhig schlafen lässt? BBCode und Wiki-Syntax wären brauchbar, aber wer mit den spitzen Klammern nicht klar kommt, dem helfen auch keine eckigen Klammern weiter. Und Wiki-Syntax ist einfach zu mächtig und noch abschreckender. Mit Textile habe ich weitgehend nur schlechte Erfahrungen gemacht, weil es gerne mal unumgehbar Sachen macht, die man so nicht gemeint hat. Markdown mag das besser machen – ich weiß es nicht – aber auch hier kann man keine ungewünschten Features entfernen und man braucht einige Disziplin, um Markdown-kompatibel zu schreiben. Mein Bruder entwickelt bei XINHA mit und schwört auf diesen Editor, aber auch XINHA ist nur eine weitere Inkarnation des von mir ungeliebten WYSIWYG-Ansatzes: Ich schreibe in erster Linie logisch (bzw. "semantisch") ausgezeichnete Inhalte und nicht Inhalte, die soundso aussehen sollen.

Einen anderen Lösungsansatz verfolgt der WYMEditor, genannt What You See Is What You Mean (WYSIWYM). Klingt sehr gut in meinen Ohren: Man arbeitet wie in einem WYSIWYG-Editor, aber sieht eine Visualisierung der benutzten Elemente und kann vor allem nur logisch sinnvolle Elemente einfügen, also keine font-Tags oder inline-Styles und so. Und hinten raus kommt valider und sauberer und logisch korrekt ausgezeichneter XHTML-Code. Eigentlich eine Selbstverständlichkeit? Finde ich eigentlich auch, naja… Leider erzeugt die aktuelle Version 0.4 keine Zeilenumbrüche oder gar (ganz verwegen) Einrückungen im erzeugten Code, so dass der von Hand nicht mehr sinnvoll bearbeitet werden kann. Schade, mal schauen, was die Entwicklung bringt. Das Potenzial ist in meinen Augen sehr groß. Vor allem wenn man das weiter denkt und Microformats integriert.