regexp: html 4 -> xhtml 1.0

[seb]

Hui, endlich mal wieder ne richtig interessante Diskussion .

Ich hab mich mit dem Problem in der Vergangenheit auch schon ausgiebig auseinandergesetzt.

Meine Haupterkenntnis war, dass Online-WYSIWYG-Bearbeitung im Browser und 100% sauberes und über externes CSS gestyltes HTML (zumindest mit den mir bekannten Open-Source-Editoren auf MSHTML- bzw. Gecko/MIDAS-Basis) unvereinbar ist.

MSHTML (die IE-Implementierung) produziert schonmal total schrottigen Code, den ich so auf keinen Fall in meine Seiten übernehmen möchte.

Bei MIDAS sieht die Sache schon wesentlich besser aus, allerdings bleibt auch dabei das generelle Problem bestehen:

Logischerweise ist auch damit zunächst nur Styling per Inline-CSS möglich, was ebenfalls unbrauchbar ist, wenn man die gesamte Ausgabe eigentlich per externem CSS formatieren möchte.

Die einzige Lösung, die ich da sehe, wäre eine aufwändige Erweiterung der WYSIWYG-Komponente mit selbstgeschriebenen JS-Funktionen (bzw. gleich ein komplett selbstgeschriebener WYSIWYG-Editor in Javascript, aber das dürfte nahezu unmöglich sein).


Aber wenn es erstmal nur darum geht, syntaktisch sauberes (X)HTML zu erhalten:
Was hältst du davon, HTML Tidy unmittelbar vor dem Speichern des Editor- bzw. Textarea-Inhalts über denselben laufen zu lassen? Damit würde jede Eingabe sofort gesübert, d.h. noch bevor sie überhaupt das erste mal in der DB gespeichert wird und du sparst dir das regelmäßige Überprüfen auf neue, noch nicht gesäuberte Inhalte.

So mach ich es bei meinem CMS und es funktioniert ganz gut (oder besser funktionierte ganz gut: Bei zwei Installationen, mit denen ich es eben grad ausprobiert hab, läuft es im Moment überhaupt nicht...dem werd ich gleich mal nachgehen).

Das ist übrigens nicht nur für das WYSIWYG-Problem nützlich, sondern auch für normale Textfelder, wo Code von "nicht ganz HTML-kundigen" Personen manuell eingegeben wird.


Und @Jürgen:

Du sagst, dass Typo3's WYSIWYG-Editor korrektes XHTML ausgeben kann. Weißt du, wie die das lösen? Verwendet das CMS auch MSHTML bzw. MIDAS oder haben die ne eigene Komponente geschrieben? Und wenn ja, wie? Java-Applet? Ist es Cross-Browser-kompatibel oder IE only?

[Jürgen]

Zitat von seb

Meine Haupterkenntnis war, dass Online-WYSIWYG-Bearbeitung im Browser und 100% sauberes und über externes CSS gestyltes HTML (zumindest mit den mir bekannten Open-Source-Editoren auf MSHTML- bzw. Gecko/MIDAS-Basis) unvereinbar ist.

Üblicherweise kenne ich das auch nicht anders und war deshalb von der Typo3-Lösung begeistert. Externes CSS ist dort kein Problem und man kann sich den Code so "herrichten", wie man das eben haben will.

MSHTML (die IE-Implementierung) produziert schonmal total schrottigen Code, den ich so auf keinen Fall in meine Seiten übernehmen möchte.

Bei MIDAS sieht die Sache schon wesentlich besser aus, allerdings bleibt auch dabei das generelle Problem bestehen:

Logischerweise ist auch damit zunächst nur Styling per Inline-CSS möglich, was ebenfalls unbrauchbar ist, wenn man die gesamte Ausgabe eigentlich per externem CSS formatieren möchte.

Im Typo3-Editor kann man Stile anlegen, die dann mit <p class="irgendeinstyle"></p> gewrapped eingesetzt werden, d. h. kein inline-CSS. Soll allerdings im RTE der Style genauso aussehen wie auf der Website, dann muss man die CSS-Definitionen in die Seitenkonfiguration von Typo3 hineinkopieren, da er für die Vorschau nicht auf das externe CSS zugreift. Aber das macht man ja ohnehin nur beim Aufsetzen der Site, also nicht das große Problem.

Aber wenn es erstmal nur darum geht, syntaktisch sauberes (X)HTML zu erhalten:
Was hältst du davon, HTML Tidy unmittelbar vor dem Speichern des Editor- bzw. Textarea-Inhalts über denselben laufen zu lassen? Damit würde jede Eingabe sofort gesübert, d.h. noch bevor sie überhaupt das erste mal in der DB gespeichert wird und du sparst dir das regelmäßige Überprüfen auf neue, noch nicht gesäuberte Inhalte.

Selbst wenn das funktioniert, was innerhalb einer bestehenden Applikation nicht leicht einzubauen ist, halte ich das aus der Sicht des Redakteurs nicht für praktikabel. Man lässt dem Redakteur alle Freiheit, bis man ihm den Code dann beim Speichern wieder wegnimmt. Frust macht sich dann wohl schnell breit. Besser ist wohl, dem Redakteur gleich von vorneherein nur bestimmte Stile zur Auswahl zu stellen, die dann vom Editor sauber umgesetzt werden. Oder lässt HTML-Tidy das Erscheinungsbild bestehen? Was macht der denn aus den font-Tags bzw. inline-Stilen?

Und @Jürgen:

Du sagst, dass Typo3's WYSIWYG-Editor korrektes XHTML ausgeben kann. Weißt du, wie die das lösen? Verwendet das CMS auch MSHTML bzw. MIDAS oder haben die ne eigene Komponente geschrieben? Und wenn ja, wie? Java-Applet? Ist es Cross-Browser-kompatibel oder IE only?

Ich glaube, der RTE von Typo3 http://typo3.org/documentation/document-library/rte/ ist eine JS-Eigenentwicklung von Kasper Skarhoj oder seinen Mannen. Basiert jedenfalls auf MS Active-X und läuft nur im MSIE. Es gibt allerdings auch Ersatz - den "HTMLArea" http://typo3.org/documentation/docum...e_pb_htmlarea/, der anscheinend auf dem Editor von Interactivetools basiert und dennoch über die Typo3-eigene Skriptsprache voll anpassbar sein soll. Der läuft dann in Gecko+MSIE. Ich habe allerdings den Standard-RTE in Verwendung.

Das Schlaue bei diesem System von Typo3 ist, dass man sowohl die Oberfläche, als auch die Codegenerierung beim Speichern völlig individuell anpassen kann. Jedes Tag, das entweder nicht zugelassen oder ersetzt werdne soll, kann definiert werden. Die Standardkonfiguration gibt in der neuen Version schon xhmtl-konform aus, man muss nur noch die individuellen Stile einbinden, die der Redakteur auswählen darf und alles andere deaktivieren. Auch das kann sehr viel Zeit in Anspruch nehmen, weil die Einstellungsmöglichkeiten eben sehr komplex sind. Aber ohne dieser Möglichkeit ist es ja wirklich ein Graus, so einen Wysiwyg-Editor einzusetzen.

[seb]

Oder lässt HTML-Tidy das Erscheinungsbild bestehen? Was macht der denn aus den font-Tags bzw. inline-Stilen?

Wie es sich genau verhält, kann ich dir nicht sagen, dazu hab ich es noch nie genau genug beobachtet oder etwas über seine Arbeitsweise gelesen.

Das Erscheinungsbild sollte es aber nicht verändern. Es verändert den Code nur insofern, als dass es Attribute in Anführungsstriche setzt, schließpflichtige Elemente schließt, unnötig komplizierte Element-Konstrukte vereinfacht usw.

Auswirkungen auf die Darstellung dürfte es also nur dann haben, wenn eine Änderung des Erscheinungsbildes durch die Korrektur eines Fehlers im Code eintrat, d.h. sich die Darstellung nach der Änderung nur deshalb von der vor der Änderung unterscheidet, weil der Code vorher fehlerhaft war und deshalb falsch interpretiert wurde.
Fehlerhaftes HTML setzt aber hoffentlich niemand absichtlich als Layoutwerkzeug ein, von daher kann man hier HTML Tidy nichts vorwerfen.

Deshalb halt ich einen Aufruf von HTML Tidy aus dem CMS heraus durchaus für eine brauchbare und vor allem überall sehr leicht einzubindende Lösung. Im Grunde wär es ja nichts mehr als ein Funktionsaufruf, dem man das zu korrigierende HTML als String übergibt und dafür das gesäuberte zurückerhält. Wenn man sich im Programmcode des CMS ein bisschen auskennt, dürfte man schnell die Stelle finden, an der man das einfügen muss.

[Jürgen]

Aha... interessant. Dann dürften aber wohl auch die font-Tags drinbleiben sowie inline-Styles usw. - denn es wird ja nur syntaktisch korrekter Code erzeugt. Gangbar ist dieser zwischengeschaltete Funktionsaufruf sicher. Aber was weiß man, an wievielen Codestellen vom Spaw-Editor in die DB gespeichert wird - das kann schon ein aufwändiges Unterfangen werden. Kenne Contenido ja nicht im Detail, aber bei Typo3 hätte man da ein Projekt für die nächsten Wochen .

Ich halte es für besser, wenn man gleich von vorneherein den Code schlank hält, indem man die Möglichkeiten für den Redakteur entsprechend einschränkt. Aber da bleiben wohl nicht viele CMS übrig, wenn man die Messlatte so hoch ansetzt.