Mehr WYSIWYG-Editoren für Weblogs

Allmählich frage ich mich wirklich, warum nicht schon viel mehr webbasierte Anwendungen (wie zum Beispiel Weblog-Tools) integrierte WYSIWYG-Editoren bieten; Editoren also, die in etwas wie ein "Mini-Word" funktionieren und keinerlei HTML-Kenntnisse verlangen, um ein Wort fett oder kursiv zu setzen. Ich hatte ja vor kurzem schon mal Kupu erwähnt (siehe WYSIWYG-Editor für Weblogs und WCMS-Plattformen). Als ich jetzt mal für ein konkretes Projekt ein wenig herumrecherchiert habe, bin ich aber gleich auf drei andere Tools gestossen, die vergleichbar leistungsfähig und vielseitig sind:

• HTMLArea
  
• FCKeditor
  
• FreeTextBox

Es gibt natürlich noch mehr von diesen Dingern, aber die vier hier funktionieren alle ganz ordentlich in den wichtigsten modernen Browsern (andere Lösungen sind oft nur für den IE oder die Mozilla-Familie erhältlich, benötigen PlugIns etc.), generieren sauberen Code und sind flexibel konfigurierbar. Bei FSKeditor liegen sogar Beispielintegrationen für die Serverseite (ASP, ASP.NET, Java, ColdFusion, und PHP) bei.

Warum also nicht mehr Blogging-Tools, Wikis etc. mit normale-Menschen-kompatiblem Editor?

OK, sicherlich ist auch ein WYSIWYG-Editor nicht die magische Kugel, die das auf einmal "total easy" macht, was heute viele als so kompliziert empfinden, dass sie davor zurückschrecken (siehe Warum normale Menschen nicht bloggen). Aber ein Anfang wäre gemacht. Und das Argument mit den "häßlichen" Artikeln, die WYSIWYG-Editoren angeblich provozieren (letztlich mal bei TwoDay gefunden) ist albern. Bei den oben genannten Editoren kann man alles, was zu "buntem Chaos" führen könnte, in wenigen Minuten abschalten. Danach produzieren die ein reines, klares XHTML, das viel sauberer ist, als das Pidgin-HTML, zu dem die heutigen Tools anhalten.

Comments

[Manfred]

Ich bin gerade über "Panda Publisher" gestoßen, ein winziges CMS, das nichts anderes regelt als die Logik der Navigation und den Einbau eines Seitentitels. Artikel und darin die vom CSS erfassten Auszeichnungen bzw. HTML-Tags muss man selber setzen. Ich halte das für vernünftig. X(HT)ML ist der Standard schlechthin, und wer es bislang nicht versteht, sollte sich wirklich mal in dieses absolut simple Gedankenschema (Container auf, Container zu) hineinzufinden versuchen. Wie Deine Beiträge über Webbasierte Software und Webapplikationen zeigen, eröffnen sich damit Welten!

Meine ComLog- und so-zi-al-Beiträge schreibe ich immer im Windows Editor; der nötige Code kommt aus in Ghost Typer XML definierten, systemweit verfügbar gemachten Textbausteinen mit Kürzeln wie #str -- strong/strong Für ein Tool wie HTMLArea müsste ich erst einen Webserver starten, ein binärer HTML-Editor ist aufwendiger als der Windows-Editor usw.

papoo CMS zeichnet sich dadurch aus, dass (zumindest) der Admin global zwischen HTMLArea und BBCode-Editor umschalten kann, je nachdem, wieviel Einfluss man auf den Code nehmen will, und in HTMLArea kann man von WYSIWYG-Editor auf HTML-Texteditor umschalten.

Und wie ich in der Vorschau dieser Kommentarfunktion gerade sehe, belässt es diese Anwendung bei Verwendung von gt;-Entities auch wirklich bei den per Hand eingefügten Entities und setzt sie nicht in ihre Anzeigeformen um (wie bei myblog.de).

[thorte]

Ich habe schon einige Male mit dem Gedanken gespielt, WYSIWYG-Editoren bei verschiedensten Projekten einzusetzen. Leider gibt es aber drei Dinge, die mich an allen von mir getesteten Editoren bisher gestört haben und die dafür gesorgt haben, dass ich die Idee wieder verworfen habe. Von den Editoren, die du aufzählst, kann ich mich aber im Moment nur an HTMLArea erinnern, deshalb ist das hier allgemeiner Natur:
1. Die Editoren müssen in allen gängigen Browsern ihren Dienst verrichten. Das ist leider nicht immer der Fall.
2. Kein von mir getesteter Editor konnte (externe) CSS-Files einbinden und mir MEINE Styles/Klassen bei der Formatierung anbieten.
3. Dem Prinzip der Trennung von (X)HTML-Source und CSS-Styleinformationen - also Inhalt und Darstellung - wird nicht (ausreichend) Rechnung getragen. Was soll ich mit Style-Definitionen im XHTML-Source? span style="..." und font ... haben da wirklich nichts zu suchen. Und IMHO ist das auch kein valides XHTML. Da lasse ich mich aber gerne eines Besseren belehren.

[Manfred]

Hi, thorte!

HTMLArea in der aktuellen Version kann nun mit Internet Explorer UND Mozilla/Firefox. Ob auch Opera, Konqueror und Safari komplett HTMLArea-fähig sind, weiß ich jetzt auch nicht auswendig, aber da muss man ohnehin fragen: Was ist ein "gängiger" Browser?

Deinen Punkt 2 verstehe ich nicht so richtig: Styles sind Formatvorlagen für HTML-Elemente - und die bieten eigentlich alle diese Web-HTML-Editoren. Also auch den Zugriff darauf über die Symbolleisten und die WYSIWYG-Umsetzung in der Textarea. So kenne ich es zumindest von HTMLArea sowohl in papoo als auch in OpenCms.
Dass sie von vornherein keinen Zugriff auf selbstdefinierte CSS-Klassen bieten, dürfte klar sein - das wären ja Wunderautomaten, wenn sie das könnten :-)

font ... ist natürlich kein valides XHTML, aber span ... MUSS ja valide sein, weil es für WAG-konforme Sprachauszeichnungen u.Ä. verwendet wird.

[mutant]

was sind "normale menschen"?
leute, die sich mit dem, was sie tun, nicht beschaeftigen wollen?
ich mein, man kann super bloggen, ohne html-kenntnisse _und_ ohne whatyouseeistmostlikelydifferentfromthestuffyou'llget-editor.
warum also schwachmatische IE-erfordernde tools verwenden?
wem nutzt es?

[Markus Breuer]

hallo mutant: obwohl der apodiktische tonfall nicht unbedingt so klingt, als wärst du an einem meinungs"austausch" interessiert, trotzdem ein, zwei fakten zum thema:

# ja, "normale menschen" wollen sich nicht mehr als unbedingt nötigt mit dem beschäftigen, was sie tun. das magst du beklagen, vielleicht hast du recht damit, aber es ist einfach so. schnöde welt. (und ich nehme an, dass es bereiche in deinem leben gibt, wo deine einstellung nicht grossartig anders ist)
# zumindest die beiden von uns getesteten der hier genannten beispieltools präsentieren - ordentlich ins system integriert - eine saubere darstellung dessen, was hinterher auf der seite erscheint. verlangt bei der systemintegration ein bisschen fruckelei mit den CSS. läuft dann aber sehr gut.
# keines der hier genannten tools setzt den IE voraus (den ich selbst zum beispiel nur noch für kompatibilitätstests verwende)

äääh .... hast du den artikel eigentlich wirklich gelesen oder dir eines der tools angesehen oder bist du einfach "grundsätzlich gegen" wysiwyg-editing?

# editoren dieser art nutzen vorwiegend solchen menschen, die sich - warum auch immer - nicht mit den "vorgängen unter der haube" beschäftigen WOLLEN, wie programmierern, die ihre anwendungen nicht mehr in assembler schreiben wollen, autoren, die ihre texte nicht mit LaTex setzen wollen, ...

[Oliver Wagner]

Wer hätte gedacht, dass über dies Thema mit so viel Leidenschaft diskutiert werden kann :-). WYSIWYG Editoren sind eine gute Sache. WYSIWYG Editoren sind aber auch eine gefährliche Sache. Bei Kundenprojekten die mit Content Management Systemen umgesetzt werden neige ich persönlich immer dazu die Funktionalität, der im Backend für die Redakteure integrierten WYSIWYG Formulare, soweit als möglich zu beschneiden. Denn schlussendlich werden wir als Agentur engagiert um ein sauberes und funktionierendes Layout zu erstellen - da ist dann viel gestalterische Freiheit (auf Redakteursebene) nicht unbedingt erwünscht. Aber für Blogs - klar, da ist das sicher für den weniger technikbegeisterten User eine gute Ergänzung, erst recht, wenn er damit auch noch Bilder hochladen und positionieren kann (kann er?).

[Markus Breuer]

oliver, es mag sein, dass du WYSIWYG-editing mit den berüchtigten "richtext-feldern" (RTF; oft ein ms-word im OLE-kleid) verwechselst, die die kunden immer begeistern, die aber auch ich vermeide wie der teufel das weihwasser. darum geht es hier nicht.

diese tools hier lassen sich so konfigurieren, dass der anwender - ohne ein hohes mass krimineller energie - tatsächlich nur saubere inhalte eingeben kann, die ordentlich über CSS gestaltet werden können. das tut grossen websites gut und weblogs auch.

im kontext komplexer websites würde ich diese tools aber auch nie so einsetzen, dass damit (nahezu) die komplette seite gestaltet werden kann sondern immer nur zur bearbeitung eingeschränkter bereiche.

WYSIWYG und sauberes layout, WYSIWYG und sauberer code sind KEIN widerspruch! tatsächlich haben wir in meinem alten unternehmen eine technologie entwickelt, die in der lage ist, komplette seiten WYSIWYG zu bearbeiten und dabei das vorgegebene layout und die definierte inhaltliche seitenstruktur perfekt einzuhalten. doch, das geht, dank XML und schemata! (die lösung ist leider nur ne nummer zu groß für ein blog und basiert auf MS-technologie). ich will damit nur sagen: dogmatik der art "WYSIWYG muss sein!" oder "WYSIWYG ist bah!" ist unprofessionell. intelligenter, sauber abgewogener einsatz der verfügbaren tools unter berücksichtigung der gestalterischen (und auch anderer!) ziele ist das, was im interesse des clienten ist. und nur das macht uns als gute dienstleister erfolgreich.

[matthias]

Na dann wird dich interessieren, dass wir (TwoDay) uns wieder einmal mit dem Thema WYSIWYG auseinander gesetzt haben. siehe http://www.matsblog.com/stories/372570/

Bin noch immer der Meinung, dass WYSIWYG zu grauslichen Format-Resultaten führen kann, aber du erwähnst auch richtig dass man ja nicht alles an formattierungen anbieten muss was möglich ist.

[Markus Breuer]

yepp! interessiert mich tatsächlich und freut mich. wobei auch die alternativen zu htmlarea interessant sind. tut sich viel in dieser richtung momentan.

> Bin noch immer der Meinung, dass WYSIWYG zu grauslichen Format-Resultaten
> führen kann, aber du erwähnst auch richtig dass man ja nicht alles an
> formattierungen anbieten muss was möglich ist.

eingabefelder, die pidgin-HTML zulassen, können noch zu viel gräuslicheren resultaten führen als ein restriktiv konfigurierter WYSIWYG-editor. dass ein solcher editor nicht "perfekt" ist, ist kein wirklich gutes argument, ihn nicht als "besser" zu erkennen. die realisierung in typepad deutet die richtung an, die mir vorschwebt. einige detail-entscheidungen hätte ich allerdings deutlich anders getroffen. aber sixapart wird auch dafür seine gründe gehabt haben.

ich denke, wie ich schon in der antwort zu olivers kommentar gesagt habe, dass deine haltung zu WYSIWYG ihre wurzeln vermutlich in den frühen RTF-feldern hat, die es leider auch heute noch gibt (zum beispiel im Microsoft CMS-System und in SharePoint). ein alter kunde von mir hat sein intranet damit fast völlig zerlegt. so etwas diskreditiert WYSIWYG - aber nur, solange man sich nicht offen und detailliert mit dem thema auseinandersetzt.