Warum ein neues WYSIWYG Plugin?

Für DokuWiki existieren eine Reihe von Plugins, die versuchen einen WYSIWYG Editor zu integrieren. Das populärste ist dabei sicherlich das von Myron Turner gepflegte CKGEdit.

Um zu verstehen warum der Ansatz von CKGEdit und ähnlichen Plugins für Wikis nicht ideal ist müssen wir ein wenig ausholen…

Das Bearbeiten von Inhalten im Browser ist kompliziert. Browser verstehen nur ein Format um Inhalte formatiert darzustellen: HTML¹⁾. HTML ist sehr mächtig und erlaubt es die komplexesten Inhalte darzustellen. Das manuelle Bearbeiten von HTML ist allerdings sehr mühsam und benötigt viel Sorgfalt und Erfahrung - keine gute Voraussetzung um mal eben etwas schnell aufzuschreiben.

Eine der Vorteile die Wikis so populär gemacht haben, ist es Anwendern zu erlauben Webseiten zu erstellen ohne auch nur eine Zeile (HTML) Code zu schreiben. Etwas Text und ein bisschen Syntax und das Wiki erzeugt daraus HTML. Bearbeitet wird immer die Syntax selbst. Das ist ein sehr einfaches und sehr stabiles System. Aus einfacher Syntax wird komplexes HTML.

WYSIWYG Editoren haben einen anderen Ansatz. Sie erlauben direkt das Bearbeiten des HTML Codes. Allerdings eben nicht als rohen HTML Code, sondern als WYSIWYG. Konkret bedeutet das, gerendertes HTML wird direkt manipuliert. Da HTML komplex ist und Browser eigentlich nur Darstellungsmaschinen sind, ist das Entwickeln eines solchen Editors bereits relativ aufwändig, auch wenn man als Eingangs- und Ausgangsformat „nur“ HTML hat.

Für Wikis kommt eine weitere Hürde hinzu: man möchte erfahrenen Nutzern weiterhin die Möglichkeit geben Wiki-Syntax zu nutzen ²⁾. Das bedeutet, es muss zwischen HTML und Wiki-Syntax hin- und her konvertiert werden. Von Wiki Syntax nach HTML ist dies einfach, die andere Richtung ist komplizierter: ein komplexes System muss sinnvoll in ein weniger komplexes überführt werden.

Der traditionelle Ansatz stößt schnell an seine Grenzen: was, wenn ich einen roten Text (zum Beispiel per Copy'n'Paste) in den WYSIWYG Editor einfüge? Roter Text ist valides HTML und wird erstmal vom Browser auch so dargestellt. Speichere ich das ganze als Wiki Syntax, geht das rot natürlich verloren. Das bedeutet aber ich habe keinen „What you see is what you get“ Editor mehr. Ich sehe roten Text, bekomme aber schwarzen Text.

Das bedeutet, dass eigentlich der Editor selbst schon sehr genau Bescheid wissen muss, was das dahinterliegende Wiki-System eigentlich kann, um dann die Eingaben darauf zu beschränken.

Dies ist genau der Ansatz, den das Prosemirror toolkit geht. Prosemirror ist eine Bibliothek die die Grundmechanismen für einen WYSIWYG Editor bereitstellt, aber keinerlei Annahmen zum Ein- und Ausgangsformat stellt. Stattdessen arbeitet der Editor intern mit einem abstrakten Modell des bearbeiteten Dokumentes. Ein Schema definiert wie dieses Dokument aufgebaut sein darf.

Der Editor konvertiert das Dokument nach HTML für die Darstellung und führt Nutzereingaben wieder in das Dokument zurück. Beim Speichern wird dann das abstrakte Dokument wieder in Syntax konvertiert - da das Schema bereits sicherstellt, dass das Dokument well-formed ist, ist dieser letzte Schritt wieder vergleichsweise trivial.