Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Aber bitte mit Filter

Aber bitte mit Filter

Egal, ob Ihr Euren Kunden einen WYSIWYG-Editor oder eine Auszeichnungssprache wie Textile oder Markdown zur Verfügung stellt: Manchmal will ein Kunde HTML-Konstrukte nutzen, die er eigentlich nicht versteht und auch nicht schnell zusammenklicken kann. Oder der Editor lässt dem Redakteur trotz aller Vorsicht die Option, das Design zu zerschießen. Ausgabefilter können da Abhilfe schaffen. Nicolai Schwarz über sein neues Lieblingswerkzeug für (und manchmal auch gegen) Kunden.

Gemälde (Ausschnitt): Carl Spitzweg, Der strickende Vorposten. 1860. Sammlung Georg Schäfer, Schweinfurt.

Ausgabefilter sind nun keine neue Erfindung. Textile oder Markdown nutzen die Technik ebensolange wie diverse Module für die unterschiedlichsten CMS. Grundsätzlich geht es dabei darum, dass bestimmte Inhalte, die der Kunde eingibt, nicht 1:1 ausgegeben werden, sondern erst durch einen oder mehrere Filter gejagt werden, die den Inhalt vor der Ausgabe verändern.

Ein einfaches Beispiel aus Textile wäre die Auszeichnung h2. Das ist eine Überschrift , die der Kunde eingibt. Der Filter macht daraus richtiges HTML: <h2>Das ist eine Überschrift</h2>. Andere simple Filter ersetzen in einem Forum vielleicht ein Semikolon-Minuszeichen-Klammerzu durch ein Smiley. Oder sie maskieren eine E-Mail-Adresse »beispiel@webkrauts.de« mit einem JavaScript-Konstrukt, um es Spam-Robotern etwas schwerer zu machen, die Adressen einzusammeln.

Diese Technik ist unabhängig von der verwendeten Programmiersprache oder dem CMS. Es kommt nur darauf an, bestimmte Texte mit regulären Ausdrücken zu filtern, um Muster zu finden und ändern zu können.

In der Regel nutzen Webworker Filter, die in einem CMS ohnehin als Modul zu Verfügung stehen. Typogrify ist zum Beispiel eine Sammlung von Typografie-Filtern, die für Django, Drupal oder Textpattern zur Verfügung steht. Nach demselben Prinzip ist es uns auch möglich, eigene Filter zu nutzen, die es auf der einen oder anderen Webseite uns oder Kunden einfacher machen. Zum Beispiel ist ein Filter sinnvoll, der zu große Bilder, die das Design zerstören könnten, entweder nicht anzeigt oder am besten gleich kleinrechnet.

Drupals Filter »URL Icon«
Drupals Filter »URL Icon« fügt bei externen Links auf Wunsch dessen Favicon oder ein Icon für externe Links an<

Filter im Eigenbau

Pro Retina ist eine Selbsthilfevereinigung von Menschen mit Netzhautdegenerationen. Dort werden Abkürzungen genutzt, die für Screenreader korrekt ausgezeichnet werden sollten: mit abbr oder acronym, einem title und ggf. einem Sprachwechsel. Zum Beispiel <abbr lang="en" title="Body-Mass-Index">BMI</abbr> oder <acronym title="Zapfen-Stäbchen-Dystrophie">ZSD</acronym>. Das ließe sich nun direkt im Editor erledigen, und die Redakteure müssten die Begriffe jeweils einzeln auszeichnen. Das ist auf Dauer etwas lästig. Geschickter ist ein Filter, der einfach [BMI] oder [ZSD] durch die längeren Versionen ersetzt. Das lässt sich schneller tippen, ist nicht so fehleranfällig und vor allem: über die gesamte Webseite konsistent.

Die Syntax mit den eckigen Klammern richtet sich nach der Syntax, die viele andere Filter auch nutzen. Wir können natürlich darüber streiten, ob die hier nötig sind. Vielleicht soll einfach jedes Vorkommen der Buchstaben ersetzt werden, dann bräuchten wir keine Klammern. Auf der anderen Seite ist es sinnvoll, dem Nutzer anzuzeigen, dass sich etwas ändert. Durch die eckigen Klammern kann er Abkürzung bewusst ergänzen lassen.

Auf campuscharts.de ging es um Bildergalerien. Dafür gibt es meist Module, die Thumbnails automatisch generieren und eine Lightbox hinzufügen. Das ist kein Problem. Nun sollte es aber möglich sein, von anderen Inhalten auf die Bildergalerien zu verlinken. Und zwar so, dass jeweils drei verlinkte Thumbnails angezeigt wurden, mit einer passenden Unterzeile. Nun hätte ich dem Kunden erklären können: Die Thumbnails liegen in jenem Ordner, die werden automatisch erzeigt, einfach drei Bilder aussuchen, verlinken, Satz drunter und gut. Das ist nicht besonders kundenfreundlich, vor allem aber wieder fehleranfällig.

Die bessere Lösung: Für jede Bildergalerie wird ein kleiner Code-Schnipsel zur Verfügung gestellt, nach dem Muster [galerie:453]. Diesen Schnipsel kann der Redakteur nun an jeder beliebigen Stelle einbauen. Der Filter sucht sich anhand der Nummer die richtige Bildergalerie heraus, stellt die ersten drei Bilder der Galerie zusammen, verlinkt und mit den richtigen CSS-Klassen, und setzt einen Satz darunter, der den verlinkten Titel der Galerie enthält. Das ist flexibel, für Kunden trotzdem einfach genug und sorgt wiederum für ein einheitliches Erscheinungsbild.

Den HTML Purifier hat bereits Michael van Laar in seinem Artikel über WYSIWYG-Editoren erwähnt. Der Purifier ist ein mächtiges Tool, das enorm umfangreich HTML prüfen und korrigieren kann. Es gibt ihn bereits für Phorum, MODx, Drupal, WordPress, bbPress, Joomla, CodeIgniter, Symfony und CakePHP. Wer PHP beherrscht, kann ihn für seine eigenen Zwecke einsetzen.
Er ermöglicht uns zum Beispiel bösartigen Code zu beseitigen, fehlende End-Tags zu schließen, falsch verschachtelte Elemente zu reparieren, CSS zu validieren oder leere Elemente auszufiltern. Außerdem können wir festlegen, welche Elemente und Attribute erlaubt sind, oder welche ids wir Redakteuren erlauben möchten. Der Purifier lohnt sich vor allem, wenn Kunden dazu neigen, aus Word zu kopieren – und der WYSIWYG-Editor alleine nicht allen unnötigen Word-Code entfernen kann.

Gedanken zur Umsetzung

Für einige stellt sich nun die Frage: Warum Ausgabefilter? Wir könnten den Filter bereits nutzen, wenn der Inhalt in die Datenbank geschrieben wird. Richtig, könnten wir. Aber wenn wir eine Ausgabe ändern wollen, ist es schlicht eleganter, das per Ausgabefilter zu regeln. Wenn wir die Webseite Pro Retina aus dem obigen Beispiel irgendwann auf HTML5 umstellen wollen, können wir im Filter einfach alle acronym durch abbr ersetzen (da es acronym in HTML5 nicht mehr gibt). Ohne dass wir die Datenbank durchgehen müssten.

Wenn viele Filter zusammen über die Inhalte laufen, muss der Webworker ggf. auf die Reihenfolge achten. In der Regel läuft der HTML Purifier zum Beispiel als letzter Filter. Die fertig gefilterten Inhalte sollten außerdem im Cache des CMS landen, damit die Filter nicht bei jedem Seitenaufruf aufs Neue starten.

Sollen Filter stillschweigend laufen – oder sollten wir unsere Kunden darüber informieren? Ich meine, es kommt darauf an. Wenn es so etwas wie den Galeriefilter gibt, muss der Kunden wissen, dass es ihn gibt und wie er funktioniert. Auf der anderen Seite kann der HTML Purifier stillschweigend im Hintergrund seine Dienste tun.

Ausgabefilter sind eine tolle Möglichkeit, seinen Kunden und sich selbst bestimmte Aufgaben einfacher zu machen. In vielen Fällen lassen sich Filter gleich für mehrere Projekte nutzen, schließlich sind sie so flexibel und universell einsetzbar.

Dieser Artikel ist die Essenz aus einem Vortrag. Die Folien dazu liegen auf SlideShare. Außerdem gibt es einen Audio-Mitschnitt des Vortrags vom Webkongress Erlangen.

»Türme bauen mit Schildbürgern (WebTech Edition)« von Nicolai Schwarz.

Gemälde (Ausschnitt): Carl Spitzweg, Der strickende Vorposten. 1860. Sammlung Georg Schäfer, Schweinfurt.

Kommentare

Peter
am 16.12.2010 - 10:15

Ich staune, dass man den HP nur als Ausgabefilter anpreist.

Es macht Sinn, den HP als erstes über eingegangene Formulardaten laufen zu lassen, ist er doch auch ein guter Helfer gegen XSS & Co. Falls notwendig läßt sich die HostBlacklist aktivieren und konfigurieren.

Zudem bietet der HP die Möglichkeit mehrerer Konfigurationen. Fein dosiert kann er so an verschiedenen Stellen im Verlauf der Verarbeitung von Daten eingesetzt werden und die Daten der jeweiligen Aufgabe entsprechend beeinflussen.

Ich nutze den HP im Zusammenspiel mit markdown extra und einigen selbstdefinierten notwendigen Ersetzungen.

Ich denke SafeHTML hat damit ausgedient, zumindest bei mir.

Ich glaube nicht, dass es den Kunden interessiert, ob und was für ein Filter wo und wie läuft.

Bei der Pflege seines Webprojektes möchte er nur auf einfach erlernbare Weise Inhalte einpflegen. Ihm selbst dürfte es dabei wahrscheinlich egal sein, ob der generierte Quellcode sauber und valide ist. Das ist unser Bier.

Hier ist Markdown nach meiner Erfahrumg ein guter Helfer. Die wenigen wirklich nötigen Auszeichnungen sind bei MD schnell erlernt. Zudem ist eine Mischung aus MD-Syntax und Html möglich, so dass auch Admins mit höheren Ansprüchen ausreichend bedient werden.

Die Kombination aus HP und MD wird bei der bwlc auch für die Kommentarfunktion eingesetzt.

Permanenter Link

Gunnar Bittersmann
am 16.12.2010 - 12:29

Ein paar kritische Randbemerkungen:

Wurde mit dem Betreiber von domain.de abgesprochen, dass seine Domain hier als Beispiel herhalten darf? RFC 2606 sagt, welche Domainnamen in Beispielen verwendet werden sollten: example.net, example.com usw.

Das Beispiel <acronym title="Zapfen-Stäbchen-Dystrophie">ZSD</acronym> finde ich nicht gelungen; nach meinem Verständnis ist ZSD kein Akronym. Für mich sind Akronyme Abkürzungen, die als Wort ausgesprochen werden, bspw. 'GIF'. Wobei es auch Mischformen gibt, bspw. 'JPEG' (jay-peg). Die Unterscheidung zwischen abbr und acronym ist aber wohl unklar, weshalb es durchaus begrüßenswert ist, dass HTML5 damit Schluss macht und das acronym-Element verbannt. Screenreader müssen wohl sowieso eigenes Wissen darüber haben, ob eine Abkürzung als Wort gesprochen wird oder ob die Buchstaben einzeln gelesen werden oder ob die Abkürzung immer ausgesprochen werden muss ('bspw.', 'usw.', 'u.a.').

Dass es keine „CSS-Klassen“ gibt, hatte ich gestern ja schon erwähnt.

Permanenter Link
Nicolai Schwarz

Nicolai Schwarz (Autor)
am 16.12.2010 - 17:14

@Peter:
In meinem Artikel geht es um Ausgabefilter, da muss ich nicht erwähnen, was noch alles möglich ist. Dazu sind ja - ganz richtig - die Kommentare da.

Und ein Kunde muss dann über einen Filter Bescheid wissen, wenn er ihn aktiv nutzen soll, wie mein Beispiel mit der Galerie.

@Gunnar:
Von der Sache mit den Beispieldomains habe ich bisher noch nie gehört. Aber ein guter Hinweis, ich habe einfach ein anderes Beispiel genommen.

Es gibt offenbar unterschiedliche Definitionen von Akronym. Relevant ist, was Screenreader daraus machen. In dem Sinne hast du vermutlich recht. Allerdings wurde mir die Abkürzung so von jemandem genannt, der einen Screenreader nutzt. Ich bin sicher, es gab einen Grund dafür. Ich kann mich nur nicht mehr daran erinnern.

Über die CSS-Klassen habe ich gestern schon nachgedacht. Wenn es um Text geht, halte ich mich schon für pingelig, aber hier halte ich das für übertrieben.
Es sind Klassen (in HTML), die wir nutzen, um das Element hinterher mit CSS zu stylen - deshalb hale ich »CSS-Klassen« für tragbar. Ich würde auch JavaScript-Klassen schreiben, um auszudrücken, dass ich diese Klassen nur in HTML einbaue, um ein Element per JS anzusprechen.

Permanenter Link

nikosch
am 17.12.2010 - 15:11

Ach ja, die perfekte, dokumentorientierte Eingabe durch unbedarfte Nutzer wird wohl die ewige Archillesferse jeder Webanwendung bleiben. Ich sehe da "Filter" durchaus zwiegespalten.

Textile bspw. kapselt schon eine Menge Funktionalität halbwegs plaintext-tauglich. Trotzdem stößt man schnell an Grenzen bei der Gestaltung, ohne HTML hineinzufrickeln. Unnütz anzumerken, dass komplexere Elemente - wie eine gefloatete Bildbox mit Unterschrift - schon wieder viel zu kryptisch für die meisten Endkunden sind.
Dass die o.g. Ersetzung nach abbr einen Pferfuß hat, erkennt jeder, der auf seiner Seite sowohl über Body mass indexes, als auch über unser Bundesinnenministerium schreibt (Leser von php.de seien an die ewige Auszeichnung jedes PR als "Page Rank" erinnert). Kurzum - das meiste an (semantischem) Markup bleibt Handarbeit, alt-Tags, Abkürzungen, title-Tags ...

Aus programmiertechnischer Sicht ist der Sinn von Filtern auch diskutabel. Wie haben Frameworks, darauf basierende MVC-Pattern, kapseln die Seiten in Templatesprachen, die Inhalte in alternativen Markups, darüber laufen dann Ausgabefilter (HTML/DOM ergänzen, Kommentare entfernen, Caching, ...) - eigentlich ein ziemlicher Wahnsinn, wohin sich das Prinzip hypertext-verlinkter Dokumente entwickelt hat!

Von Wysiwyg fange ich erst gar nicht an.

Permanenter Link

Die Kommentare sind geschlossen.