Freitag,
13. April 2012

Die Fragen danach, ob man HTML5 bereits produktiv einsetzen kann, werden zunehmend weniger. Es hat sich die allgemeine Sichtweise durchgesetzt, das dem so ist. Um dabei auch die alten Browser(-versionen) nicht außen vor zu lassen und die zahlreichen neuen HTML5-Elemente und JavaScript APIs browserübergreifend nutzen zu können, stehen zahlreiche Polyfills zur Verfügung. Die Aufgabe eines Polyfills ist es, die Funktionalität eines HTML5 Features mit Hilfe von JavaScript nachzubilden.

Vor wenigen Tagen ist die erste Ausgabe eines brandneuen, deutschsprachigen Online-Magazins namens mag.js erschienen und darin ein lesenswerter Beitrag von Matthias Reuter zum Thema “Mit jQuery alten Browsern HTML5 beibringen”. Darin beschreibt er, wie mittels jQuery das Placeholder-Attribut in alten Browsern nachgerüstet werden kann.

Das Placeholder-Attribut liefert einen zusätzlichen Hilfetext für Formularelemente (<input>, <textarea>), der immer dann erscheint, wenn das betreffende Formularfeld leer und nicht focussiert ist. Man kennt derartige Hilfetexte schon seit langer Zeit (seinerzeit vielfach über Inline-Event-Handler zusammengebaut), weshalb das Placeholder-Attribut auch eines der HTML5-Features war, die bereits frühzeitig in allen modernen Browsern implementiert wurden.

Aber zurück zum JS-Beispiel des oben genannten Beitrags. Das Beispiel zeigt mit sauberem und gut dokumentiertem Code, wie man mittels weniger Zeilen JavaScript den Placeholder-Text über das blur-Event als Wert in das leere Formularfeld schreibt (der Platzhalter wird sichtbar), bzw. über das focus-Event wieder löscht, um Nutzereingaben zu ermöglichen. Und an dieser Stelle beginnen auch die Probleme mit der nachträglichen Implementation, denn es wird ein Wert (der Platzhalter) in das Formularfeld geschrieben, der eigentlich keiner ist.

Matthias Reuter ist sich dieses Problems auch bewusst, denn vor dem Absenden des Formulars müssen die eingefügten Platzhalter natürlich wieder entfernt werden, um nicht als vermeintlich gültige Werte an den Server gesandt zu werden. Dafür hängt sich das Script in den Submit-Event.

Das alles ist sauber und ist auch problemlos einsetzbar, solange “nur” ein HTML-Formular dargestellt und die Daten an einen Server versandt werden sollen. Allerdings gibt es auch Anwendungsfälle, die darüber hinaus gehen und wobei dieses und die meisten anderen Placeholder-Polyfills versagen. Das Problem der vorstellten Implementation ist, dass die Implementation des Polyfills nicht scriptfähig ist, also keinen dynamischen Zugriff auf den Wert des Formularfeldes per JaveScript berücksichtigt.

$('input').val();

Es macht einen Unterschied, ob der Polyfill aktiv ist oder die native Implementation des Browsers, denn während in einem modernen Browser die Abfrage eines leeren Inputfelds ein leerer String ergibt, erhält man bei aktivem Polyfill den Wert des Placeholders zurück. Ein Zustandstest im Sinne von:

if ($('input').val() == "") { 
    // do something
}

... ist deshalb crossbrowser nicht mehr fehlerfrei möglich. Und das fällt einem möglicherweise bei der clientseitigen Formularvalidierung und insbesondere bei der Entwicklung von Webapps mit Formularelementen unangenehm auf die Füße. Ich habe dafür ein kleine Demo (JSFiddle) mit dem Plugin-Code von Matthias Reuter gebaut. Schaut Euch das Ergebnis der Input-Abfrage einfach mal im IE8 oder dem Firefox 3.6 an.

Unter html5-now.appspot.com kann man denn bezüglich des placeholder-Attributs nachlesen: “It’s easy to replicate but not in a satisfactory way.”

Genau diese Situation empfinde ich momentan als so schwierig für Frontend Entwickler, denn einerseits gibt es zur Lösung dieses Problems allein im Modernizr Wiki nicht weniger als 11 verschiedene Implementationen, wobei man entweder per trail & error herausbekommt, ob der Polyfill in der eigenen Applikation so arbeiten wird, wie man es erwarten würde, oder sich mühsam durch den jeweiligen Code graben muss, um mögliche Schwachstellen zu entdecken, die in der Dokumentation nur allzu gern verschwiegen werden. Mit anderen HTML5 Features verhält es sich ähnlich. Viele Polyfills decken genau das ab, was der Entwickler für die eigene Anwendung benötigte. Aber nur die wenigsten Projekte schreiben sich die exakte Abbildung der Spezifikation ins Pflichtenheft und pfegen ihre Polyfills regelmäßig.

Das von html5please quasi “offiziell” empfohlene Placeholder-Polyfill macht vom Code her einen guten Eindruck, denn es sind get- und set-Funktionen für die Werteübergabe vorhanden. Getestet habe ich es nicht, denn ich verlasse mich bei Polyfills bereits seit einiger Zeit auf die stetig wachsende und kontinuierlich gepflegte Webshims Lib von Alexander Farkas.

Der große Vorteil dieser Bibliothek ist einerseits, dass sie sehr einfach konfiguriert werden kann und mithilfe von z.B. yepnope selbstständig alle entsprechend der Konfiguration benötigten Features testet und benötigte Polyfills selbstständig nachläd und andererseits, das sich Alexander Farkas bei allem stets an der Spezifikation orientiert und auf die scriptfähigkeit seiner Polyfills achtet. Dazu gehören auch Hilfsfunktionen, die beispielsweise das dynamische Einfügen von HTML5-Elementen ins DOM ermöglichen – ein für komplexere Webapplikationen unersetzliches Feature. Erst seit ich diese Bibliothek kenne, setze ich HTML5 Features bewusst und weitgehend ohne Bauchschmerzen in meinen eigenen Projekten ein.

Bleibt zu sagen: Augen auf bei der Arbeit mit Polyfills. “Einfach nur einen Brocken JavaScript auf das Problem werfen und fertig” ‐ ist eine schöne Vorstellung, funktioniert in der Praxis leider allzu oft nicht zufriedenstellend.

 


Du kannst die Kommentare zu diesen Eintrag durch den RSS 2.0 Feed verfolgen. Du kannst einen Kommentar schreiben, oder einen Trackback auf deiner Seite einrichten.

Dieser Eintrag kann nicht mehr kommentiert werden.