WYSIWTEWYTS
29. April 2008 – 13:51 Uhr
»What You See Is What The Editor Wants You To See«
WYSIWYG (»What You See Is What You Get«) beschreibt die Möglichkeit, die Bildschirmdarstellung eines Editors (Textverarbeitung, Layoutprogramm, Tabellenkalkulation etc.) derart zu generieren, dass sie dem gedruckten Ergebnis entspricht. Und es soll heute tatsächlich Software geben, der das in einigermaßen guter Annäherung gelingt.
Was soll nun WYSIWYG bei einem Blogartikel-Editor bedeuten?
Dass der gerade zu schreibende Artikel schon im Editor so aussieht, wie er nach der Veröffentlichung im Blog (also an der Web-Oberfläche) aussehen wird? Wohl kaum, denn dazu müsste er ja das Stylesheet des Blogs zur Darstellung im Editor laden. Belehrt mich im Falle eines Editors, der das wirklich macht.
Oder aber der Editor stellt dem Autor einen bunten Strauß an Möglichkeiten zur Formatierung (nicht bloß zur Auszeichnung!) anheim und stellt diese bei Einsatz auch gleich in seiner Textarea sichtbar dar. In diesem Fall würde er letzten Endes mittels Inline-Styles Vorgaben des Stylesheets überschreiben, was im Sinne der sauberen Trennung von Quellcode mit Auszeichnungen und gestalteter Form keine wirklich gute Lösung darstellt.
Darüber hinaus handelte es sich eben nicht wirklich um WYSIWYG, denn ich sehe im Editor ja nicht das, was ich schließlich bekomme, sondern das, was der Editor mir formatiert anzeigt. In seinem Textarea-Fenster, das alles andere als die Browseransicht des Blogs ist. Also WYSIWTEWYTS.
Komfort?
Es mag nun das Argument geben, dass es für den Schreibenden doch angenehmer und übersichtlicher sei, wenigstens schon in etwa beim Schreiben sehen zu können, wie seine Textabsätze, Aufzählungslisten, Überschriften usw. am Ende aussehen werden.
Nun, ich vertraue in diesem Fall voll und ganz der Qualität des eingesetzten Stylesheets und kümmere mich beim Schreiben nicht um gestalterische Aspekte – ich meine, das ist doch gerade der Witz an einem Stylesheet, dass ich ihm die gestalterische Aufgabe überlasse und mich auf den Inhalt und die Struktur meines Artikels konzentriere.
Wirkliches WYSIWYG
In Fällen, in denen ich z.B. bei bestimmten Formulierungen oder inhaltlichen Feinstrukturierungen Zweifel habe, ob das am Ende auch lesbar aussehen wird, verwende ich die – zumindest bei WordPress vorhandene – Möglichkeit der Artikel-Voransicht, die garantiert präziser ist als jeder Editor, weil alleine sie wirklich echtes WYSIWYG darstellt.
Arbeitskomfort mit dem Quellcode-Editor
Meinen WordPress-Quellcode-Editor habe ich komfortabel ausgestattet mit einer ganzen Reihe zusätzlicher Quicktags, die ich beim Schreiben häufig benötige:
Die hierfür zuständige Datei heißt ›quicktags.js‹ und befindet sich (bei WordPress 2.5) im Verzeichnis /wp-includes/js . Sie lässt sich relativ einfach erweitern, indem man geeignete Codeblöcke kopiert, wieder einklebt und die gewünschten HTML-Tags in der jeweiligen Kopie einsetzt.
Ich habe wirklich alle Artikel in diesem Blögchen* mit dem Quellcode-Editor geschrieben und kann bis heute nicht darüber klagen. Ich empfehle übrigens, zur besseren Übersicht dessen Zeilenanzahl in den Einstellungen/Schreiben auf wenigstens 20 bis 25 zu erhöhen.
*In meinem Testblog verwende ich gelegentlich diesen TinyMCE, den WordPress alternativ anbietet.
Dieser Inhalt (Textbeitrag und Fotos) ist unter einer Creative-Commons-Lizenz BY-NC-ND lizenziert.
Im Autohaus wird...
Dir auch einen guten Rutsch! Hokey
Am 29. April 2008 um 15:51 Uhr
Hallo,
generell hast du natürlich damit recht, dass man seine Artikel eher als Quellcode verfassen sollte, damit man die Formatierungen des stylesheets behält.
Aber diese WYSIWYG-Editoren sind ja nicht in erster Linie für Webmaster geschrieben, die sich sowieso schon mit HTML auskennen, sondern für den Laien, der auch mal ein paar Textstücke in seinen (Blog-)Einträgen formatieren möchte und sich nicht mit Tags auseinandersetzen will.
Beim Editor, den WordPress benutzt, werden übrigens keine Inline-Stylesheets ausgegeben, sondern wird bei einem klick auf “kursiv” tatsächlich ein -Tag generiert. Damit bleibt der Code doch immer noch schön valide!
Am 29. April 2008 um 19:36 Uhr
Da stimmt ich dir voll und ganz zu!
Am 29. April 2008 um 20:13 Uhr
Tatsächlich ist der in WordPress mitgelieferte (sogenannte) WYSIWYG-Editor eher rudimentär ausgestattet, indem er lediglich auszeichnet, nicht aber formatiert. Im Grunde setzt er visuell das an Struktur um, was der Quellcode-Editor als Tags sichtbar stehen lässt.
Insofern macht er das Editieren/Schreiben für HTML-Fremde natürlich übersichtlicher. Was ich durchaus für akzeptabel und erfreulich halte.
Am 29. April 2008 um 23:04 Uhr
was ich persönlich als großen Vorteil bei direkter Auszeichnung via HTML-Tags empfinde, ist: Man mancht sich viel mehr Gedanken darüber, was man hervorheben möchte
Einmal hier ein <strong> und dort ein <em> gesetzt – ist auch nix anderes wie fett schreiben oder doppelt unterstreichen.
cu, w0lf.
Am 1. Mai 2008 um 12:46 Uhr
Ich habe mich um 2003 intensiv mit dem “Richtexteditor” beschäftigt. Inzwischen gibt es natürlich eine Reihe von Tools, mit denen die zum Teil erheblichen Qualitätsmängel abgefangen werden, aber von der üblichen Iframe-Lösung losgelöst vom Layout des Internetauftritts halte ich immer noch nicht viel.
Wesentlich besser finde ich den CONTENTEDITABLE-Ansatz direkt im Layout, denn erst dann wird deutlich, wie sich die Inhalte präsentieren.
Das Arbeiten im Quelltext ist nicht jedermanns Sache und auch nicht immer sauber umgesetzt. Gerade bei modernen Designs auf DIV-Basis kann da viel schief gehen. So lange es eine Qualitätssicherung wie zum Beispiel in WordPress gibt, mit der offene Tags automatisch geschlossen werden, kann Quelltext auch Autoren angeboten werden, die keine Ahnung haben, was die “spitzen Klammern” bedeuten.
Da die Menschen unterschiedlich sind und darum auch die Arbeitsweisen, finde ich, dass beide Lösungen ihre Berechtigung haben. Im Quelltext habe ich als Autor mehr Möglichkeiten, Richtext ist besser geeignet für Mengentext.
Autoren sollten jederzeit wechseln können zwischen den Editoren und auch ihre primäre Editoren wählen können.
Am 2. Mai 2008 um 14:50 Uhr
Wesentlich einfacher zu erlernen als HTML sind alternative Auszeichungen wie Textile oder Markdown, da sie über einen arg reduzierten Satz verfügen und die Notation wesentlich kürzer und einfacher ist. Anstelle von Tags wird häufig nur ein Zeichen benutzt. Das kommt gerade jenen zu Gute, die kein HMTL können, kennen oder können bzw. kennen wollen.
Ich fahre damit beim Bloggen seit Jahr und Tag recht gut. Und am Ende kommt valider Markup heraus.
Damit lassen sich auch längere Texte, die später mal zu HTML werden sollten, sehr komfortabel mit dem Plaintexteditor der Wahl schreiben.