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.

Nochmal zu Floats

Das Konzept, ein Layout zu beschreiben, indem man einzelnen Elementen eine Breite x zuweist und lediglich deren Ausrichtung links- oder rechtsbündig innerhalb des Elternelements bestimmt, ist keine Erfindung von CSS. Sowas gibt es schon sehr viel länger. Ich kenne ein solches System beispielsweise von der Erstellung von Benutzeroberflächen für den Amiga. Bei Software für dessen dessen Desktop-Oberfläche (Workbench) war schon in den 80er Jahren schlau, sich auf sehr unterschiedliche Bildschirmauflösungen und skalierbare Fonts einzustellen. Aus diesem Grund waren Floats für mich auch nie ein Mittel, welches allein zur Contentgestaltung herangezogen werden sollte. Wenn dem so wäre, hätte man im CSS Standard die Eigenschaft float auch einfach nur für das Image-Element definieren können. Dem ist aber nicht so.

Ich setze Floats seither sehr gern ein, weil ich sie mittlerweile in allen Browsern sehr robust geworden sind auch für die älteren Browsergenerationen gut dokumentierte, stabile Workarounds für die wichtigsten Bugs existieren. Nicht umsonst arbeiten die Layoutmodule von YAML mit Floats.

Dennoch wünsche ich mir eine Verbesserung der aktuellen Situation, denn auch wenn ich bisher fast jedes an mich herangetragene CSS-Problem lösen konnte, ist dies in – aus meiner Sicht zuvielen praxisrelevanten Standardaufgaben – nur mühsam zu erreichen. Als Beispiele wären da ...

Containing Floats

Wir benötigen eine Eigenschaft, die es ermöglicht, floatende Elemente durch den Elterncontainer sauber umschließen zu lassen. Aktuell nutzen wir dazu CSS-Eigenschaften wie overflow:hidden oder display:table, die diesen Effekt quasi als Nebenprodukt mitliefern. Da es uns in diesen Fällen aber gar nicht um das Verstecken übergroßer Elemente (overflow:hidden) oder das Rendern von Tabellen (display:table) geht, schleppen wir die Auswirkungen dieser Eigenschaften als störende Nebeneffekte zwangsläufig mit.

Was wir benötigen, damit Floats leichter handhabbar werden, ist CSS-Eigenschaft, die das Einschließen floatender Kind-Elemente zur Hauptaufgabe macht, wie z.B float:contain;. Die vom CSS-Standard dem am nächsten kommende Eigenschaft ist clear. Allerdings ist sie für Inhaltskonzepte konzipiert, weswegen ihre Wirkungsweise uns für Layoutzwecke solche Probleme bereitet und uns an diesem Punkt nicht weiterhilft.

Flexible Breiten & Source Order

Bei der Umsetzung flexibler (responsive) Layouts stößt man unweigerlich auf Probleme, wenn fixe und flexible Seitenbereiche nebeneinander zu platzieren sind. Wir platzieren sekundäre Inhalte typischerweise am Rand (Stichwort: Sidebar), neben den zentral gelegenen Hauptinhalten. Die Reihenfolge der Inhalte im Quelltext sollte die Relevanz natürlich widerspiegeln, womit auch hier erst der Hauptinhalt und dann die sekundären Infos folgen sollten. Diese Markupkonstellation stellt uns aber hinsichtlich des Layouts mit Floats vor ein konzeptionelles Problem, da laut CSS-Standard das Element, welches umflossen werden soll (hier bricht die inhaltsbezogene Ansatz von Floats im CSS-Standard durch), im Quelltext zwingend vor den Elementen, stehen muss, die es umfließen (man achte auf die aktive/passive Formulierung).

Das Problem sind hier nicht die Floats ansich, sondern dass wir kein Layout-Modul in CSS kennen, welches dieser Aufgabe gewachsen ist. Die Aufgabe besteht darin, die zur Verfügung stehende Gesamtbreite in einen Bereich mit definierter Breite (Maßeinheit em,% oder px) und einen flexiblen Rest zu unterteilen. Genau dieser flexible Rest ist in CSS nur für statische Elemente spezifiziert über width:auto. Auf positionierte (position:absolute|fixed) oder floatenden (float:left|right) Element lässt sich diese Breitenangabe aber nicht anwenden.

Deshalb ist es uns ohne Tricksereien nicht möglich, eine horizontale Zweiteilung durch zwei “gleichwertige” Layoutbausteine vorzunehmen. Wir greifen mangels Alternativen auf Floats zurück, wobei hierbei immer der Zwang besteht, dass das floatende Element im Quelltext vor den statischen Element stehen muss.

Natürlich ist es dennoch möglich, dieses Problem mit den aktuellen Bordmitteln zu lösen. Entsprechend Codebeispiele dafür habe ich in die Dokumentation des Spaltenmoduls von YAML aufgenommen (achtet auf die verschiedenen Layoutansätze für 2-Spalter). Das ganze geht zurück auf die cleveren Ansätze aus dem Beitrag “In Search of the Holy Grail” von A-List-Apart vom Januar 2006. Seither sind 6 Jahre vergangen, in denen sich CSS enorm weiterentwickelt hat. Dieses Grundproblem flexibler Layouts wurde jedoch bisher nicht zufriedenstellend gelöst.

User Interfaces für Webapplikationen

Als drittes möchte ich nochmal darauf hinweisen, dass gemäß der Logik der CSS-Spezifikation Webseiten eine definierbare Breite haben, in ihrer Länge aber grundsätzlich als unendlich definiert werden, weswegen es im Grunde keine Möglichkeiten gibt, den vertikalen Layoutaufbau sinnvoll zu gestalten, außer durch den linearen Aufbau des Markups und einer abschnittsweisen Gestaltung der aufeinander folgenden Elemente (Header, Content, Footer). Der CSS-Standard ist für HTML-Seiten konzipiert, das vertikale Scrollen gehört quasi zum Konzept dazu, um die theoretisch unendliche Informationsmenge einer HTML-Seite durch das Schlüsselloch Browserfenster (mit begrenzten Dimensionen) betrachten zu können. Schon für einen sticky Footer nutzen wir CSS-Kniffe, die ein Großteil von CSS-Einsteigern nicht mehr voll durchdringt und deshalb nur schwer auf die eigenen Randbedingungen anpassen kann.

Nun hat sich aber der HTML5 Standard auf die Fahnen geschrieben, HTML fit für Webapps zu machen. Befeuert wird diese Entwicklung durch potente Smartphones und Tablets. Man will eine echte Alternative zu nativen Applikationen schaffen, die naturgemäß für jedes OS separat entwickelt.

Der Gedanke ist ausgesprochen reizvoll, jedoch ist einer der grundlegenden Unterschiede, dass User Interfaces in nativen Applikationen anders funktionieren als eine Website. Niemand will auf der Suche nach einem wichtigen Funktion erst mühsam nach unten scrollen müssen, um dann für den Klick auf einen Menüpunkt wieder nach oben zu scrollen usw. Ihr versteht, was ich meine?

Es geht also um User Interfaces, die mit dem verfügbaren Platz in horizontaler und vertikaler Ausdehnung auskommen müssen/sollen – ohne Scrollen. Im CSS-Standard haben wir nichts, womit diese Aufgaben zu bewältigen wären. Der aktuelle Umweg geht hier über JavaScript. ExtJS bietet in seinen UI Komponenten so genannte Layout Manager, für jQuery gibt es das von mir hoch geschätzte Layout Plugin. Speziell auf den Mobilbereich ausgelegt, gesellen sich Projekte wie jQuery Mobile und Sencha Touch hinzu.

Diese JavaScript-basierenden Tools liefern uns die Layoutwerkzeuge, ohne die es kaum denkbar wäre, webbasierte Applikationen zu schreiben, die sich wie eine native App anfühlen. Dennoch stelle ich mir die Frage, ob wir es uns dauerhaft leisten wollen, Layoutaufgaben, die eigentlich der Browser für uns viel schneller und effizienter lösen könnte, an JavaScript auszulagern. An anderer Stelle diskutieren wir bis aufs Messer um jedes Byte, was wir aus Performancegründen weglassen können. Beim Layout jedoch sind wir jedoch JavaScript praktisch ausgeliefert, was nie so schnell werden kann wie die hardwarebeschleunigte Rendering-Engine eines Browsers (oder eben die des Betriebssystems, die jeder nativen App zur Verfügung steht). Und das hat auch die Konsequenz, dass eine native App sich – zumindest aus dieser Sicht – immer flüssiger anfühlen und reagieren wird als eine clientseitige JS-Implementation.

Damit will ich den gedanklichen Steifzug durch meine CSS-Phantasien beenden. Wichtig war mir, aufzuzeigen, dass wir Layouts aktuell noch mit vergleichsweise unausgereiften Techniken bauen, obgleich die technischen und qualitativen Anforderungen an CSS-basierte Layouts durch die heutige Vielzahl der Endgeräte enorm gestiegen ist und ich neben den tollen CSS3 Entwicklungen der letzten Jahre (Schatten, Gradienten, Webfonts, Animationen, etc), die niemand mehr missen will, hier eigentlich dringender Nachholebedarf und erhebliches Potential performantere Lösungen besteht. Auch habe ich mich bei dieser Liste ausschließlich auf die Belange des Seitenlayouts beschränkt. Schaut man sich andere Bereiche, könnte man hier sicherlich endlos weitere Wünsche ergänzen.

Was wir aber nicht können, sind vermeintlich simple Layoutaufgaben ohne abstruse CSS-Tricksereien realisieren. Schon vor einer kleinen Weile schlug Louis Lazaris mit seinem Blogbeitrag “CSS: The Bad Parts” in eine ähnliche Kerbe, wobei ich nur zum Teil die von ihm angesprochenen “Probleme” als solche wahrnehme.

Die Sache mit den Floats

Über den Sinn und Zweck von Floats lässt sich trefflich streiten. Vor 5..6 Jahren waren sie der Heilsbringer, der die CSS-Layouts dahin geführt hat, sich über den Layouttabellenschmarn des letzten Jahrhunderts zu erheben. Und in einem Umfeld, in dem überwiegend pixelexakte Layouts propagiert wurden, funktioniert dieser Ansatz auch leidlich. Nun hört man in den letzten Jahren – anfangs nur von Standards-Fetischisten – heute auch aus der breiten Frontendler-Masse, Floats wären ja laut Standard nie für Gestaltungsaufgaben vorgesehen gewesen und würden demzufolge für Layoutzwecke genauso missbraucht, wie seinerzeit die HTML-Tabellen.

Nun, diese Argumentation mag für Verschwörungstheoretiker brauchbar sein, für mehr aber auch nicht. Viel schwerwiegender ist doch die Erkenntnis, dass sich Floats trotz aller Widrigkeiten im Detail der Spezifikation durchgesetzt haben und wir monentan gar keine Alternativen dazu haben. Und damit bin ich wieder beim Aufhänger für diesen Blogpost. CSS 3 hat in den letzten 2 Jahren eine rasante Entwicklung hinter sich und vom Gefühl her beschleunigt diese Entwicklung noch immer. Nur passiert der technische Fortschritt auf ganz anderen Bereichen: Runde Ecken, Gradients, Schatten, Animationen, 3D, Schriften usw. usw.

All die neu hinzugekommenden CSS3 Features will man aber nun auch einsetzen und damit werden viele der Probleme, die es mit Floats gibt, erst jetzt mit Nachdruck sichbar. Umso unbefriedigender ist die Tatsache, dass mit CSS3 bisher kaum brauchbare Layoutkonzepte in die Standardisierung – geschweigedenn in die Praxis – Einzug gehalten haben.

Kein Float-Clearing ohne Nebenwirkungen

Wer bis heute der Meinung ist, die Clearing-Problematik wäre mit der Erfindung des Clearfix-Hacks gelöst, der führt zum einen ein offenbar gut behütetes Entwicklerleben und irrt zum anderen gewaltig. Schauen wir auf die aktuellen Webdesign-Trends: Responsive Webdesigns, flexible Grids und CSS3 Box-Shadows.

• Der Clearfix-Hack hat das Ärgernis beseitigt, für das Clearing der Floats zusätzliche Elemente ins Markup stopfen zu müssen. Er hat aber schon immer das Problem, Auswirkungen auf die Positionierung anderer floatender Elemente im gleichen Kontext zu haben, was seinen Einsatzzweck zum Einschließen von Floats stark einschränkt.
• Die Eigenschaft overflow:hidden schien zur Hochzeit von CSS2 nahezu nebenwirkungsfrei zum Einschließen von Floats. Mit der Praxistauglichkeit von CSS3 ist dieser Status dahin, denn CSS-Schatten von Child-Elementen werden an den Elementrändern gnadenlos abgeschnitten.
• Die Eigenschaft display:table scheint auf den ersten Blick die Nachteile von overflow:hidden mit CSS3 ausgleichen zu können, denn es wird nichts abgeschnitten. Dafür ist die Implementation in den Browsern uneinheitlich, was schon damit beginnt, wie sich ein Element mit dieser Eigenschaft hinsichtlich seiner Breite verhält. Dazu kommt ein noch tiefer liegendes Problem, welches nicht immer sofort sichtbar wird. Die Eigenschaft display:table hebelt eines der grundlegenden Rendering-Prinzipien von CSS aus, dass ein Elterncontainer nicht mit der Breite seines Kind-Elementes mitwächst. Sichtbar wird dieses Verhalten, wenn man beispielsweise flexible Grids damit baut und linearisiert, ohne den einzelnen “Zellen” eine Breite zuzuweisen (wozu auch, Blockelemente dehnen sich von allein auf die Größe des Elternelementes aus). Fügt man in ein solches CSS-Konstrukt allerdings ein flexibles Bild ein, wird dieses plötzlich nicht mehr skaliert dargestellt, sondern in voller Größe und die Elterncontainer werden entsprechend ausgedehnt – genauso wie bei Tabellen. Dieses Problem ist bisher kaum bekannt. Aber ihr könnt mir glauben, es ist extrem mühsam, die eigentliche Ursache beim Debugging überhaupt zu erkennen.

Mit dem Durchbruch flexibler Layouts unter dem Deckmantel des Buzzwords “Responsive Design” werden weitere Probleme sichtbar. Wir sind bei CSS weit davon entfernt, Elemente unabhängig vom Markup im Screendesign anordnen zu können. Zahlreiche Entwickler bemerken erst jetzt bei der Umstellung von fixen Grid-Systemen auf Grids in Prozentwerten, was es heisst, mit Rundungsfehlern der Browser offensiv umzugehen. Und und und ...

Fehlende Alternativen

Tja, was gibt’s hier? Der eine oder andere weiß sicher, dass einige CSS-Frameworks (z.B.: die Grid-Komponente von YUI3) auf display:inline-block aufbauen. Auch diese Eigenschaft ist keine Lösung, denn sie wurde noch viel weniger für Layoutzwecke entworfen als Floats. Das äußert sich insbesondere darin, dass ein Grid mit diesem CSS-Konzept plötzlich höchst sensibel auf Leerzeichen und Zeilenumbrüche im Quelltext zwischen den einzelnen Grid-Zellen reagiert. Es braucht nicht viel Phantasie, um sich die Probleme vorzustellen, wenn man als Entwickler keine vollständige Kontrolle über den Quellcode hat. Und wer hat die schon? Denkt nur an verschachtelte Templates in einem CMS und die dadurch entstehenden Zeilenumbrüche im Quelltext.

CSS3 verspricht uns gleich vier neue Layout-Module: Multicolumn, Grid-Layout, Flex-Box und das Template-Modul. Das Multicolumn-Modul ist als einziges bereits beim Status “Testing” angekommen allerdings lässt es sich im Grunde nur auf Fließtext sinnvoll anwenden. Für den Bau eines Seitenlayouts im herkömmlichen Sinne ist es ungeeignet. Die anderen drei pendeln zwischen “Revising” und “Exploring”, d.h. ihre Anwendbarkeit liegt in weiter Ferne. Erschwerend kommt hinzu, dass der visuelle Seitenaufbau ein so grundlegender Baustein ist, dass sich hier kaum sinnvolle Progressive-Enhancement-Strategien realisieren lassen. Entweder die gesamte relevante Browserlandschaft unterstützt die Technik fehlerfrei oder sie ist für den Alltag noch nicht reif. Sprich: Wir lesen uns 2016 wieder.

Während wir mittlerweile selbst auf Smartphones gut und gerne 50 animierte Kühe per CSS fliegen lassen können, mühen wir uns bei den grundlegenden Gestaltungswerkzeugen im Web auch in den nächsten Jahren noch mit unzureichenden Techniken ab. Und es verblüfft mich schon ein wenig, dass wir uns so bereitwillig von all dem HTML5- und CSS3-Bling Bling blenden lassen.

Nachtrag: Für die Zweifler unter Euch: Zwar keine fliegenden Kühe, dafür nicht minder knuffige, fliegende Schweine. (gefunden und mir zugetragen von Christian Heilmann).

Ich lernte Micha 2007 kennen, als er mich eines Nachmittags anrief, um sich von mir das O.k. für die Veröffentlichung seines ersten Wordpress-Themes auf Basis von YAML zu holen. Er rief an, weil er gelesen hatte, dass ich auch aus Görlitz käme und so entstand mehr oder weniger über Nacht eine Freundschaft, die über die Jahre immer enger wurde. Seither haben wir unzählige Stunden am Telefon, sowie den einen oder anderen Nachmittag in Görlitzer Cafes beim Schwatzen verbracht, wann immer es sich anbot.

Micha war ein Fan von YAML und er war seit je her begeistert von Wordpress. Und er war es, der vor über zwei Jahren damit begann, das in die Tat umzusetzen, wovon ich für YAML immer geträumt hatte. Ein Werkzeug, welches die zahlreichen Features von YAML auf einfachem Wege für ein CMS nutzbar macht, ohne dabei die Gestaltungsfreiheit von YAML maßgeblich einzuschränken, wie es allzuoft bei “vorkonfigurierten” Themes oder CMS-Templates der Fall ist.

Das Ergebnis wurde am 1. November 2010 mit der Veröffentlichung von XtremeOne sichtbar, einem unglaublich vielseitigen Theme-Framework für Wordpress, basierend auf einer speziell angepassten Version von YAML 3, welches in seinen Features und seiner Flexibilität konkurrenzlos ist. Wir haben uns gegenseitig angespornt bei unseren Projekten und für mich war Micha derjenige, der die Philosophie hinter YAML und meine Vorstellung davon, was sich auf der Basis von CSS Frameworks für tolle Ideen realisieren lassen, am besten verstanden und zugleich in die Tat umgesetzt hat. XtremeOne hat sich zu seinem Lebenswerk entwickelt und seine Begeisterung für das Projekt war unglaublich.

Am 24. Februar 2012 ist Michael Preuß nach kurzer, schwerer Krankheit verstorben. Noch wenige Tage zuvor hatten wir telefoniert: er hatte Pläne geschmiedet, neuen Mut geschöpft. Und plötzlich den Kampf viel zu früh verloren.

Mit XtremeOne wird es weitergehen. Micha hat dieses Projekt gemeinsam mit Heiko Rabe und Alex Frison auf die Beine gestellt und sie werden die Weiterentwicklung übernehmen. Nähere Infos dazu findet Ihr in dieser offiziellen Mitteilung im Projektblog. Falls Ihr Eure Anteilnahme bekunden wollt, tut dies bitte im XtremeOne-Blog. Danke.

“Dirki, die Besten kommen halt aus Görlitz, oder?”

Mit dieser Frage beendete er nicht wenige unserer Gespräche.

Ja Micha, das tun sie. Und Du warst einer von Ihnen.

Die Überschrift Eures heutigen Beitrags “Contao: Open-Source-CMS mit HTML5” ist ein schlechter Witz. Der einzige Bezug des gesamten Beitrags zu Eurem Lieblings-Buzzword “HTML5” findet sich im ersten Satz:

Contao ist ein Open-Source-CMS, das auf PHP basiert und HTML5 unterstützt.

Das war’s. Bis zum Ende des Beitrags kommt der Autor kein zweites Mal auf HTML5 zu sprechen.

Bitte, was soll das? Gibt es bei Euch noch eine Redaktion, die sich der inhaltlichen Abstimmung der Beiträge verpflichtet fühlt, oder redigiert und veröffentlicht jetzt nur noch Euer Marketing die Beiträge?

Ich habe in der Vergangenheit zu verschiedenen Themen und auf verschiedenen Kanälen (Skype, Twitter, Kommentare, Blogposts) Feedback an Eure Redaktion weitergegeben. Doch die konstruktive Kritik scheint Euch nicht zu interessieren.

Das ist schade, denn scheinbar bemerkt ihr auch nicht, dass Ihr damit auch dem vorgestellten Projekt Contao keinen Gefallen tut. In Bezug auf HTML5 ist der Beitrag noch nicht einmal enttäuschend. Er geht völlig am Thema der Überschrift vorbei. Dabei gäbe es wirklich interessante Fragen. Jedes halbwegs gute CMS überlässt heute dem Anwender die Kontrolle über das Markup des Seitenlayouts. Aber spätestens bei den Inhalten wird es spannend, denn z.B. bei Formularen muss man sich bei fast jedem CMS mit irgendwelchen Generatoren oder Plugins auseinandersetzen. Diese haben nämlich meist eigene Vorstellungen hinsichtlich des verwendeten Markups und lassen dem Anwender selten Wahlmöglichkeiten, solange man nicht selbst willens und fachlich dazu in der Lage ist, teils tief in den Code einzugreifen. Ein Paradebeispiel dafür ist nach Hörensagen das Formularmodul von Drupal. Wie es hier bei Contao und dem Einsatz von HTML5 Formularelementen (und deren Validierung) momentan bestellt ist, wäre durchaus hochinteressant zu erfahren gewesen. Oder was hinsichtlich der dynamischen Verwendung von HTML5 Elementen hinsichtlich IE6/7/8 Support zu beachten ist? Bei jQuery ist dafür seit v1.7 innerShiv integriert. Contao arbeitet jedoch standardmäßig mit Mootools. Wie läuft das da?

Stattdessen folgt auf das Buzzword-Bingo (2x HTML5 innerhalb der ersten zwei Zeilen) nur eine, sagen wir durchschnittliche, Vorstellung des Content-Management-Systems. Da fragt man sich natürlich: Warum gerade jetzt? Denn auf das vor 2 Wochen erschienene Release 2.11 und dessen Neuerungen geht der Beitrag genauso wenig ein.

Ihr seid das Fachmagazin. Wie kann es sein, dass Ihr auf solche Fragen nicht kommt und Euch dieses Informationsniveau für Eure Leser ausreichend erscheint?

Kommen wir zu dem Punkt, warum ich mich überhaupt darüber aufrege: Weil ... ich mir mehr deutschsprachige Fachblogs und Online-Magazine zum Thema Frontendentwicklung wünsche, sich aber leider keine Alternativen aufdrängen. Gleichzeitig verstehe ich nicht, warum es den vielen anderen Frontendentwicklern da draußen so egal ist, wohin sich das T3N Magazin seit einiger Zeit entwickelt. Das Smashing Magazine ist vor 2..3 Jahren ähnlich in die Kritik geraten mit ihren endlosen “10 best anything” Toplisten-Artikeln und es hat viel Kritik von außen und sicher sehr viel mehr Kraft von innen bedurft, um das Ruder wieder herumzureißen.

Aber vielleicht erwarte ich ja auch einfach nur zuviel vom Online-Bereich des “führenden deutschsprachigen Printmediums zu den Themen Web 2.0, Social Media, E-Business und Open Source”.

Ich hoffe, in Eurer Redaktion ist noch jemand wach.

Begeistert hat mich das soziale Netzwerk schon seit seinem Start. Ich bin mit meinem privaten Account seit Anfang an dabei und habe die Offenheit und Kommentierfreudigkeit der dortigen Community schätzen und lieben gelernt. Und obwohl ich anfangs meine Zweifel hatte, wie lange diese Euphorie wohl anhalten würde (schließlich fehlen noch immer eine gute öffentliche API und demzufolge auch Apps), bin ich bisher treu geblieben. Der zu Twitter vergleichbare Ansatz, Usern, deren Meinung man schätzt, einfach folgen zu können, führt zu einem angenehmen Klima in meiner Timeline.

Mit diesen Erfahrungen im Hinterkopf stellte sich mir Anfang Januar die Frage, wie ich beim Relaunch von YAML.de mit dem Entwicklerblog weiterverfahre. Bis dahin lief die umfangreiche, zweisprachige Website auf einer recht mühsam eingerichteten und pfegeintensiven Typo3 Installation und diese - das stand bereits fest - würde mit dem Relaunch einer Webpräsenz aus simplen statischen Seiten weichen müssen. Das alte Developer-Blog setzte auf Wordpress und damit eigentlich auf eine sehr angenehme Arbeitsumgebung. Doch es war nie wirklich erfolgreich gewesen. Einerseits sind in 4 Jahren kaum mehr als 20 Beiträge darin veröffentlicht worden, andererseits hat es auch nie eine gute Reichweite entwickelt, denn die RSS-Zugriffszahlen und Kommentare hielten sich in sehr überschaubaren Grenzen. Das waren für mich zwei gute Gründe, auch Wordpress den Laufpass zu geben und ein Experiment zu starten mit einer Projektseite bei Google+.

Die Vorteile sind dabei schnell erläutert. Der Administrationsaufwand sinkt auf ein Minimum und ich kann mich voll und ganz auf die Inhalte konzentrieren. Der Nachteil - den man immer auch im Hinterkopf haben muss - ist, ich pflege meine Inhalte nicht mehr auf meiner eigenen Domain (in meinem eigenen Haus). Für mein privates Blog wäre dieser Gedanke auch heute unvorstellbar. Für das Entwicklerblog von YAML war es bisher eine ausgesprochen gute Entscheidung.

Was ist seither passiert?

• Ich habe 19 Blogbeiträge veröffentlicht.
• Ich habe bisher 101 Kommentare erhalten.
• Meine Beiträge wurden 75 Mal von anderen Nutzern geteilt,
• und 154 Mal mit einem “+1” versehen.
• Die Seite hat mit Stand heute 1519 Follower.

Soweit die technischen Daten. An dieser Stelle ist ein Vergleich zu Twitter interessant, denn auch dort bin ich mit dem Account @yamlcss seit Oktober 2009 aktiv und habe dort bei 143 Tweets bis heute 1897 Follower bekommen. Für mich sind beide Kanäle momentan unverzichtbar, aber es zeigt, wie rasant Google+ wächst und vor allem bin ich von der Kommentarfreudigkeit und der Gesprächskultur auf Google+ begeistert. Beides fehlt auf Twitter mehr oder minder, Twitter ist nunmal ein Push-Nachrichtenkanal, wirkliche Kommunikation stand bei diesem Dienst noch nie im Vordergrund. Und zuletzt war auch die Entscheidung, den Blog bei Google+, wie auch den Twitter-Account, in Englisch zu befüttern aus heutiger Sicht eine gute Wahl. Die Follower verteilen sich sehr gleichmäßig rund um den Globus, was mich sehr freut, denn erstmals habe ich das Gefühl, meine Zielgruppe wirklich zu erreichen.

Und das soll es als erste Einschätzung auch gewesen sein. Die ersten Schritte sind gemacht, ich fühle mich in meinem Konzept bestätigt und freue mich darauf, wie sich das Projekt in den nächsten Monaten weiterentwickelt.

Das neue Dokumentationskonzept

Die Dokumentation von YAML wurde vollständig neu gestaltet. Sowohl 2005 (YAML 1) als auch 2007 (YAML 3) erschien es gerechtfertigt, neben dem “wie” der Anwendung auch das “warum” der technischen Realisierung) ausführlich zu erläutern. Es gab in diesen Jahren kaum vollständige Dokumentationen zum Umgang mit Browserbugs und die Grundkonzepte von CSS2 waren für viele Entwickler noch vergleichsweise frisch. Diese Zeiten sind vorbei. Grobe CSS-Bugs, die massiv das Rendering einer Webseite beeinflussen, sind in den aktuellen Browsern mehr oder weniger ausgestorben, die Macken der alten Browsergeneration sind in zahlreichen Büchern und online umfassend dokumentiert. Zudem war die YAML-Doku in ihrer PDF-Fassung auf satte 150 Seiten angewachsen, die Pflege und Fortschreibung in zwei Sprachen war nicht mehr zu leisten.

Das neue Dokumentationskonzept behandelt zukünftig nur noch die Anwendung der einzelnen Features – also das “wie”. Lohn dieses neuen Konzepts: die Doku liegt nun als offline-taugliche HTML-Datei dem Zip-Paket des Frameworks bei und dient gleichzeitig als Kurzreferenz. Code-Schnipsel können direkt per copy & paste in das eigenen Projekt übernommen werden. Dafür steht die Dokumentation zukünftig nur noch in englischer Sprache zur Verfügung. Mir ist es sehr wichtig, eine möglichst gut verständliche und vollständige Dokumentation liefern zu können, weshalb mich in der Vergangenheit immer wieder kleine Unterschiede in den Sprachversionen gestört haben. Die CSS Dateien des Frameworks sind hingegen auch weiterhin überwiegend zweisprachig dokumentiert.

Nun zu den wichtigsten Neuerungen bei YAML selbst. Im März 2011 hatte ich ja bereits über einige der geplanten Änderungen bei YAML 4 gesprochen. Wer die Ankündigungen verfolgt hat, wird über die folgenden Dinge nicht mehr ganz so überrascht sein.

Namespaces

Eine der häufigsten Quellen für Probleme bei der Frontendentwicklung in Verbindung mit Content Management Systemen, speziell bei größeren oder über Jahre gewachsenen Projekten, sind Kollisionen von ID- und Klassennamen der bestehenden Inhalte mit dem neu zu integrierenden CSS Framework. Dies fängt bei so beliebten Systemen wie Wordpress an, welches per default (und nicht ganz einfach zu unterbinden) die CSS Klasse .page an das <body>-Element vergibt und damit bereits mit der gleichlautenden Klasse von YAML 3.x kollidiert.

Ein weiteres Problem waren große, gewachsene Webprojekte. CSS-Klassen, wie .wrapper oder .col1 sind seit vielen Jahren gebräuchlich. Hat ein Projekt erst einmal eine gewisse Größe erreicht (ich rede hier von einigen tausend Seiten), ist die Wahrscheinlichkeit sehr gering, dass bei einem Relaunch wirklich alle Inhalte auf den neuesten Stand gebracht werden können. Im Regelfall wird man es neben einigen frisch aufbereiteten Seiten mit viel Legacy-Code zu tun haben, der unvorhersehbares Konfliktpotential mit sich bringt.

In YAML 4 werden daher die CSS-Klassen (IDs werden durch das Framework nicht mehr definiert) der Kernbestandteile des Frameworks mit dem Präfix ym- versehen. Nicht jeder wird sich über diese Regelung freuen, denn zumindest ein wenig leidet immer auch die Lesbarkeit der Klassennamen. Entsprechend des Anwenderfeedbacks der letzten Jahre überwiegt in diesem Fall aber klar der Nutzen.

HTML5, CSS3 und veraltete Browser

Aus technischer Sicht gibt es im Grunde kaum eine Neuheit, denn YAML unterstützt bereits seit Version 3.3 von Hause aus HTML5 und auch für den Umgang mit CSS3 waren die 3.x Versionen technisch bereits bestens gerüstet. Dennoch hat sich hier eine Kluft zwischen der Codebasis des Frameworks und dem äußeren Eindruck des Projektes ergeben, denn die alte YAML-Seite und insbesondere die Layoutbeispiele waren optisch tief und fest im Erstellungsjahr 2007 verankert und wirken seit einiger Zeit angestaubt und altbacken. Und so war es nur logisch, dass YAML nicht nur den CSS-Support für die neuen HTML5 Elemente mitbringt, sondern dass die beiliegenden Layoutbeispiele diesen Weg auch aktiv beschreiten.

Der Internet Explorer 6 wird von YAML noch immer unterstützt. Hier gibt es keine qualitativen Einschnitte im Kern des CSS Frameworks. Das ist auch nicht notwendig, denn YAML hat die notwendigen Anpassungen für den IE6 und 7 schon immer separat (in der Datei iehacks.css) verwaltet. Geändert hat sich jedoch die Verwendung dieser Datei. In YAML 4 gibt es darüber hinaus keine gesonderten Patch-Stylesheets für den IE mehr, die iehacks.css wird fortan direkt über den Conditional Comment eingebunden. Das bedeutet andererseits, dass ich in den Beispiellayouts keine Anstrengungen mehr unternehme, den bei Spaltenlayouts typischen 3-Pixel-Bug manuell zu fixen oder per JS-Expression einen Ersatz für den fehlenden Support für min-width / max-width mitliefere. Für letzteres gibt es bei Bedarf effektiven Ersatz in Form von Respond.js. Wer darüber hinausgehend weiterhin auf den Feinschliff für den IE6 nicht verzichten will, dem steht der 3.x Versionspfad von YAML, einschließlich des YAML Builders auch weiterhin zur Verfügung. Man kann sich dort auch weiterhin noch an den verwendeten Techniken bedienen.

Für den HTML5 Support im IE6-8 setze ich auf html5shim. In diesem Projekt gibt es aktuell viel Bewegung, es ist daher jedem, der tiefer in HTML5 einsteigen will empfohlen, sich mit den aktuellen Diskussionen und der Weiterentwicklung des Projekts zu beschäftigen.

Flexibilität eines CSS Frameworks

YAML wurde in der Vergangenheit als ein System beschrieben, welches ein mehr oder weniger umfangreiches bzw. fertiges Basislayout mitliefert. Aus diesem löscht der Anwender, was er im jeweiligen Projekt nicht benötigt. In Version 1 konnte YAML nicht viel mehr, weshalb dieses Erklärmodell in der Anfangszeit durchaus stimmig war. Über die nachfolgenden 6 Jahre hat sich das Projekt jedoch deutlich weiterentwickelt. Der Framework-Charakter wurde immer stärker herausgearbeitet und das Projekt durch zahlreiche optionale Bausteine (Grid-Elemente, Formulare, usw.) ergänzt.

Heute erwarten die Anwender eines CSS Frameworks eine klare Trennung der Framework-Logik vom Screen-Design. Eine Sammlung, aufeinander abgestimmter Bausteine (Layout, Navigation, Typographie, Formulare, Print), um effektiv und schnell Prototypen realisieren zu können. Flexibilität, nicht zwingend im Screen-Design selbst, sondern in Handhabung des Frameworks ist gefragt. Ein Wechsel des Gridrasters von 12 auf 24 Spalten oder der Wechsel von einem fixen Grid auf eine fluides, sollte nicht dazu zwingen, auch das CSS Framework selbst wechseln zu müssen. Wer ein Layout wahrhaft responsive gestalten will, braucht kein «Responsive Framework» mit einem willkürlich vorgegebenen Linarisierungspunkt, welcher sich an der Displayauflösung aktueller Smartphones ausrichtet – diese sind unter Umständen in 6 Monaten bereits wieder veraltet. Der Umbruch der einzelnen Layoutvarianten eines adaptiven Layouts sollte individuell für jedes Design bestimmt werden. Frontententwickler benötigen hierfür möglichst praktische und einfach zu handhabende Werkzeuge – das ist die Aufgabe des CSS Frameworks. Und in diesem Sinne habe ich YAML weiterentwickelt.

YAML 4 bietet deswegen keinen fest vorgegebenen Wert zur vollständigen Linearisierung der Layout-Module. Stattdessen wähle ich den Weg über eine progressive Linearisierung des Layouts in mehreren Stufen. Über die Anzahl der Stufen und die Übergangspunkte hat der Anwender vollständige Kontrolle und, obwohl das recht komplex klingen mag, die Anwendung ist letztlich sehr einfach und komfortabel. Was YAML nicht mitliefert, sind technische Lösungen für die bandbreitenoptimierte serverseitige Auslieferung von Medien (Bildern, Videos). Das ist erstens nicht die Aufgabe eines CSS Frameworks, zweitens gibt es zahlreiche Projekte, auf die im Bedarfsfall zurückgegriffen werden kann.

Die neue Website

«Eat your own dog foot» ist nicht nur ein geflügelter Satz, es war schon immer Programm in meinen Projekten. Es ist deshalb nur logisch, dass es mit YAML 4 sowohl eine neue Website, als auch neue Layoutbeispiele geben musste, die sich auf dem aktuellen Stand der Technik bewegen, nämlich HTML5, CSS3 und Responsive Design. Drei Schlagworte, die im letzten Jahr leider z.T. Buzzword-Charakter angenommen haben, worüber ich ja auch schon ein paar Worte hier im Blog verloren habe. Unabhängig davon finde ich jedoch, dass ein CSS Framework nicht nur versprechen, sondern auch zeigen sollte, was die angebotenen Features zu leisten im Stande sind – und zwar im Produktivbetrieb und nicht nur in einfachen HTML-Demos.

Lizenzbedingungen und ein neues Lizenzmodell

Mit dem Release von YAML 4 veröffentliche ich auch neue, anwaltlich geprüfte Lizenztexte für die beiden bisherigen kommerziellen Lizenzmodelle von YAML, die Projektlizenz und die Generelle Lizenz. Bei Erstellung der Texte wurde darauf geachtet, dass der Status Quo der Nutzungsrechte erhalten bleibt und sich für bestehende Projekte und Lizenznehmer keine Änderungen ergeben. Die Lizenztexte sind auf YAML.de vollständig in englischer Sprache hinterlegt. Neben der englischen Fassung gibt es die Lizenztexte natürlich auch in Deutsch - nachzulesen in Kürze (1..2 Tage brauchen wir noch) im YAML-Shop.

Neu hinzugekommen und sicherlich interessant für CMS-Projekte, Templateshops oder Theme-Frameworks ist die OEM-Lizenz. Über dieses neue Lizenzmodell wird es möglich, YAML fest in andere Projekte zu integrieren und die Nutzungsrechte an Endkunden übertragbar zu gestalten. Als Beispiel hierfür sei das Wordpress-Framework Xtreme One genannt, welches bereits seit dem Sommer 2011 mit einer solchen OEM-Lizenz ausgestattet ist und Endanwendern automatisch die vollen Nutzungsrechte für YAML sichert.

Nachtrag: Die offiziellen (etwas knapper gefassten) englischsprachigen Release Notes gibt es hier drüben. Die YAML Website auf Google+ wird zukünftig auch der von mir favorisierte Nachrichtenkanal sein. Deutschsprachiges und persönlich angehauchte Infos gibt’s natürlich weiterhin hier.

Sublime Text 2 kommt mit einer ganzen Reihe verschiedener Color-Schemes daher. Ich persönlich mag dunkle UIs, weil ich oft bis tief in die Nacht programmiere und kann das Monokai-Theme empfehlen (gibt’s übrigens auch für Coda).

Eines der Highlights des Editors sind die zahlreichen Plugins. Zunächst solltet Ihr Euch aber Package Control installieren, einen bequemen Paket-Manager für Sublime Text 2. Über diesen könnt Ihr dann bequem aus Liste die zu installierenden Pakete auswählen, die Installation geschieht in der Regel vollautomatisch. Als Empfehlung hier eine kleine Auswahl der bei mir installierten Pakete:

• Alignment - erleichtert die Ausrichtung des Quelltextes, z.B. vertikale Ausrichtung an Gleichheitszeichen
• BracketHighlighter - Hervorhebung zusammengehöriger Klammern
• Sublime JSLint - vollautomatisiertes Linting für JavaScript Code aus dem Editor heraus. Bequemer geht es nicht mehr
• Tortoise - Speziell für Windows User interessant, erweitert es den Editor um Menüeinträge und Keyboard-Shortcuts zur Ansteuerung von Tortoise, dem defakto Standard-SVN-Client unter Windows
• Zen Coding - komplexes Plugin zur Code-Vervollständigung für HTML & CSS

JSLint Konfiguration

Obgleich das JSLint Plugin auf Anbieb funktioniert (um eine Java-Runtime braucht man sich nicht kümmern, die kommt gleich mit), ist es dennoch sinnvoll, dem Linter ein wenig Wind aus den Segeln zu nehmen, um nicht von tausenden angeblichen Fehlermeldungen zugeschüttet zu werden. Die Konfiguration erfolgt über ein Config-File, welches man im Editor selbst über Preferences->Package-Settings->JSLint->Settings-Default erreicht.

Unter “jslint_options” kann man hier den Linter entsprechend der eigenen Vorlieben anpassen. Folgende Optionen habe ich gesetzt:

—predef $,document

Wer wie ich viel mit jQuery arbeitet, wird um die Option predef nicht herumkommen. Sie dient dazu, JSLint über globale Variablen zu informieren, auf die der zu prüfende Code zugreift und deren Benutzung somit nicht als Fehler gewertet wird. Für jQuery sind das mindestens $, bzw. jQuery und document.

—white

Ist meinem persönlichen Coding-Stil geschuldet, dass ich nicht von JSLint über die Verwendung von Leerzeichen belehrt werden will.

—browser

Damit werden typische gobale Variablen der Browser verfügbar, z.B. window.

—sloppy

Sollte immer aktiviert werden, solange man noch nicht mit “use strict”; arbeitet.

Das ganze sieht dann fertig so aus:

// Options pass to jslint.
"jslint_options": "--predef $,document --white --sloppy --browser"

Eine vollständige Liste der Optionen gibt es hier. Hat man das hinter sich gebracht, kann man den Linter jederzeit mit Crtl+J anschmeißen und sich anschließend gemütlich durch die Fehlerliste navigieren. So bequem hatte ich es bisher in keinem Editor.

Die Vorgaben des Print-CSS kann ich allerdings weniger empfehlen (ist aber auch weniger dramatisch). Speziell geht es mir um die “Print Friendly Links”, wie es der oben zitierte Beitrag nennt. Hier der betreffende Auszug aus dem HTML5 Boilerplate.

a[href]:after { content: " (" attr(href) ")"; }
abbr[title]:after { content: " (" attr(title) ")"; }
.ir a:after, a[href^="javascript:"]:after,
a[href^="#"]:after { content: ""; } /* Don't show links for images, or javascript/internal links */

Ich habe Vergleichbares (Automatische Auszeichnung von URLs, Akronymen und Abkürzungen) seit vielen Jahren in den YAML Druckstylesheets integriert, allerdings bin ich recht schnell wieder einen Schritt zurück gegangen, indem ich diese Regeln nur noch auskommentiert mitliefere und das aus gutem Grund.

Es ist auf den ersten Blick sicher nachvollziehbar, dass verlinkte URLs beim Druck verloren gehen und man als zuvorkommender Webentwickler diese deshalb hinter dem Linktext mit ausdrucken will, damit für den Anwender der Quellenverweis erhalten bleibt. Doch mal ehrlich: Wie oft hat jeder von Euch im letzten Jahr eine auf Papier abgedruckte URL in den Browser eingetippt? Und wie oft war diese dann länger als 10 Zeichen? Ist die pauschale Ausgabe von URLs also wirklich sinnvoll?

Aus dem anvisierten Komfort für den User wird in der Praxis schnell ein Nerv-Feature – und meist auch der Regelfall. Im Gegensatz zum Print arbeiten wir im Netz nicht mit Quellenverzeichnissen am Ende des Textes, sondern verlinken Schlagworte oder ganze Sätze direkt und im Idealfall auch recht umfangreich. Allerdings steht im Netz die Querverlinkung dem Lesefluss und -genuss auch nicht im Wege. Ausgedruckt ist ein solches Dokument allerdings nur noch bedingt gut lesbar, wenn der Fließtext regelmäßig durch lange, kryptische, nicht umbrechbare URLs unterbrochen wird. Ganz zu schweigen davon, dass sich die Mehrzahl der Anwender eben nicht diebisch darüber freut, eine neue URL zum Abtippen gefunden zu haben.

Gleiches gilt für die Anzeige der title-Attribute von Abkürzungen. Gute Schreibe gebietet, dass Abkürzungen bei ihrem ersten Auftauchen im Text eingeführt/erläutert werden. Aber eben nur beim ersten Mal (vielleicht noch beim zweiten, dann ist aber gut). Das Einpflegen von Akronymen und Abkürzungen erledigt im HTML aber fast niemand von Hand - weil es recht lästig und umständlich ist. Dafür gibt es bei vielen Content Management Systeme entsprechende Plugins, die diese Aufgabe automatisch anhand von Wortlisten übernehmen. Auch daran gibt auf den ersten Blick nichts auszusetzen, denn schließlich wird das title-Attribut nur angezeigt, wenn der Anwender das Element mit der Maus ansteuert und darüber verweilt. Aber schon Nutzer von Screenreadern dürften derartige Automatismen stören, wenn z.B. in einem Webdesign-Fachtext hinter jedem jedem HTML (Hypertext Markup Language) steht/vorgelesen wird. Und Lesern eines ausgedruckten Dokuments geht es da nicht anders.

Die sichtbare Auszeichnung von URLs und Abkürzungen ist per Definition weder unnütz noch schädlich. Allerdings ist sie eben nur dann sinnvoll, wenn die Inhalte entsprechend sorgfältig dahingehend aufbereitet sind, in dem beispielsweise nur die URL von besonders gekennzeichneten Links ausgegeben wird. Genauso wie der Ausdruck der title-Attribute von Abkürzungen nur dann für den User sinnvoll ist, wenn die Texte auch entsprechend sorgfältig aufbereitet werden. Andernfalls kann beides schnell zum billigen Werbefeature des Entwicklers werden, welches u.U. deutlich an den Interessen des Lesers (Internetausdruckers) vorbei geht.

Und so versteckt sich auch im HTML5 Boilerplate die eine oder andere Regel, deren Nutzen mehr Schein als Sein ist, wenn man sie gedankenlos übernimmt.

Das neueste Projekt in dieser Hinsicht ist ein sechsstündiger jQuery Video-Workshop von Gerrit van Aaken, der seit ein paar Tagen bei Undsoversity zum Kauf bereit steht und sich ausdrücklich an Einsteiger richtet. Um sich vor dem Kauf einen Eindruck vom Gebotenen verschaffen zu können, stehen insgesamt drei Kapitel (Events und EventListener, Inline-Bildergalerie und ein interaktiver HTML5-Videoplayer) mit einer Gesamtlänge von fast 2 Stunden (fast 1/3 der Gesamtlänge) kostenfrei auf YouTube bereit.

Aufgebaut sind die einzelnen Themenblöcke als Live-Coding Sessions in denen zu Beginn eine Aufgabe vorgestellt wird, die im Anschluss als “Blick über die Schulter” des Tutors mit HTML, CSS und eben jQuery (Anm: JavaScript sage ich hier bewusst nicht, denn JavaScript scheint kaum thematisiert zu werden) gelöst werden. Die Art und Weise der Präsentation finde ich von Konzept her gelungen und besonders interessant für Autodidakten (wie mich), die lieber durch Probieren als durch dumpfes Lesen neue Dinge lernen. Der Zuschauer kann die schrittweise Entwicklung des Programmcodes anhand konkreter Aufgabenstellungen miterleben und so dessen Logik sehr viel einfacher nachvollziehen, als beispielsweise aus einem spärlich kommentiertem, 2-seitigen Abdruck eines fertigen Quelltextes in einem Buch.

Weniger gut gelungen ist die Umsetzung dieses Konzepts. Das Live-Coding ist eine hohe Kunst und offenbart immer dann seine Tücken, wenn der Tutor nicht auf den Punkt vorbereitet ist. Ein bewusst eingebauter Logikfehler im Code zum Zwecke der Demonstration des Debuggings oder eines wichtigen logischen Schritts, ist sicherlich sinnvoll und lässt den Workshop authentisch und “lehrreich” wirken. Zuviele kleine Korrekturschleifen in zu kurzer Abfolge (speziell im Video-Kapitel) wirken hingegen mit der Zeit eher störend. Beim Herauskopieren von Code-Schnipseln aus anderen Webseiten rinnen die Minuten der erkauften Zeit sehr viel schneller als man denkt. In einem kostenlosen Screencast, ist sowas kein Problem. In einem kostenpflichtigen Lernvideo wünsche man sich dann doch ein etwas zielgerichtetes Arbeiten und Erklärungen mit mehr Tiefgang anstatt reinem copy/paste (Stichwort: Mediaelement.js).

Gerrits Workshop richtet sich an Einsteiger ohne JavaScript-Kenntnisse. Der Einstieg erscheint auch butterweich, allerdings hätte ich mir gewünscht, dass man über 18 Kapitel nicht nur die Komplexität der Aufgaben, sondern auch den Anspruch an den Coding-Stil schrittweise steigert. So hätte man meiner Meinung nach nicht gänzlich auf das eine oder andere Standard-Pattern für eine strukturierte JS-Programmierung verzichten müssen. Selektoren, die innerhalb weniger Zeilen 4..5 Mal aufgerufen werden (teilweise auch innerhalb von Schleifen), darf man schonmal cachen. Das mag für die konkreten Beispiele nicht lebenswichtig sein, hilft aber auch Einsteigern ein Gefühl für mögliche Performance-Probleme zu entwickeln für den Fall, dass auch mal größere Mengen an DOM-Manipulationen von Nöten sind. Guten Stil muss man nicht zwingend theoretisch belehrend herunterbeten, gerade Einsteigern kann man ihn leicht vermitteln, indem man ihn einfach vorlebt.

Deutliche Kritik muss man an dem Kapitel zum interaktiven HTML5-Videoplayer üben, denn dessen Codequalität ist wirklich erschreckend schlecht. In diesem Kapitel sollen Produktinformationen zeitsynchron zu einem Video angezeigt werden. Die dafür erforderlichen Daten werden per Ajax vom Server dynamisch nachgeladen. Allerdings wird auf das Ergebnis dieses Ajax-Requests zugegriffen, ohne überhaupt auf dessen Existenz zu prüfen, bzw. auf seine Verfügbarkeit zu warten. Eine Callback-Funktion für einen Ajax-Error (sowas soll’s ja auch geben) gibt’s ebenfalls nicht. Die Daten werden einfach als “verfügbar” erklärt. Variablen werden nicht deklariert (sie werden dadurch zwangsweise global), eine Strukturierung des Codes – auch im Sinne einer einfacheren Wiederverwendung – findet nicht statt. Die globalen Variablen sind schon deshalb ein Problem, weil bereits bei einem zweiten Video gleicher Art auf der Seite, das Script sich zwangsläufig selbst die Werte überschreibt. Dass dieses Codebeispiel überhaupt funktioniert, ist mehr als glücklich. Denn die Asynchronität der success-Callbacks, die sich aus dem Ajax-Request, wie auch aus der Initialisierung des Videoplayers ergeben, wird weder angesprochen, noch im Code berücksichtigt und ich bin mir nicht sicher, ob dem Autor das Problem vollständig bewusst ist. Hier hat mindestens die Qualitätskontrolle versagt, wenn es denn eine gab.

An einer Stelle wird “unobtrusive JavaScript” erwähnt, kurze Zeit später jedoch Teile einer Webseite initial per JavaScript, sorry: jQuery, ausgeblendet, die nur bei Interaktion sichtbar werden sollen. Damit wird das Konzept von unobtrusive JavaScript auf den Kopf gestellt, denn das Ausblenden funktioniert ohne JavaScript nunmal nicht, genauso wie das zugehörige interaktive Feature. Das ist ein konzeptioneller Fehler, der ebenfalls vermeidbar gewesen wäre. Auf diese Weise summieren sich kleine und große Unsauberkeiten.

Ich arbeite nun schon seit über vier Jahren mit jQuery und habe in den Anfangszeiten neben einigen schnellen Erfolgen auch massenweise Fettnäpfe erwischt, in die ich mangels besseren Wissens, schlechter Tutorials und unperformanter Plugins gestolpert bin. Gerade wenn mit dem Rückenwind der ersten Erfolgen der Mut wächst, sich an größeren Aufgaben zu versuchen, ist ein sauberer Stil und ein solides Grundwissen nicht zu ersetzen. Deshalb hat mich Gerrits schnippische Antwort auf einen berechtigten, kritischen Kommentar von Alexander Farkas (welcher auf weitere Probleme aufmerksam macht) aus seinem eigenen Blog sehr gewundert. Zitat:

Was ist schon schlechter Programmierstil? Und vor allem: Was ist guter? Darüber wirst du viele verschiedene Meinungen finden. 

Richtig ist, dass man vieles aus dem Workshop eleganter und effizienter lösen kann. Aber es ist ein Einsteiger-Workshop mit einem gewissen Crashkurs-Charakter. Da kann man nicht stundenlang über Code-Qualität theoretisieren. [...], denn in ein paar Stunden »Über die Schulter gucken« bringt man den Leuten eben am besten solche Dinge bei, die sie sofort anwenden können.
[...]
Das Schöne an jQuery ist doch gerade, dass damit Einsteiger schnell (und dreckig) zu tollen Ergebnissen kommen. [...] Würden alle Webdesigner deine Maßstäbe anlegen, gebe es deutlich weniger spannende Anwendungen von jQuery.

Das (und ganz besonders die von mir fett hervorgehobenen Passage) hat mich vom Hocker gehauen. Es ist das eine, was man im Alltag mit jQuery/JavaScript anstellt. Es ist aber etwas anderes, wenn man vorgibt, Einsteigern etwas beizubringen zu wollen und sein Wissen zu Geld machen will. Da führt um Sorgfalt und Qualität kein Weg herum.

Egal, wie viel oder wenig Zeit man für die Vermittlung von Wissen hat. Man kann einen Einsteiger auf irgendeinen Weg führen oder auf den Richtigen. Man wird ihn auf beiden Wegen nur ein paar erste Schritte begleiten können und man kann ihm auf beiden Wegen schnelle Erfolge präsentieren. Der Unterschied besteht in der Zeit danach, wenn die Käufer eines mit 39,99 EUR (Einstiegspreis: 34,99 EUR) im Vergleich zu den Videotrainings einiger renomierter Verlage nicht unbedingt günstigen Video-Workshops, eigenständig weiterlaufen sollen. Jede Handwerker-Lehre beginnt damit, dass die Azubis lernen, dass man sein Werkzeug ordentlich behandelt und den Arbeitsplatz regelmäßig aufräumt. Schwer vorstellbar, dass in einem Video-Workshop für angehende Webentwickler derartige Werte keinen Platz mehr finden müssen.

Gerrit weist in seinem Blogbeitrag ausdrücklich auf die angenehmen wirtschaftlichen Rahmenbedingungen bei Undoversity hin:

Timo erledigt Produktion, Marketing, Vertrieb, Technik und Controlling in Eigenregie und ist dadurch mehrere Dimensionen effizienter als ein beliebiger Verlag es je sein könnte. Und das kommt natürlich auch den Tutoren zugute. Dass mein Anteil am Verkauf signifikant höher ausfällt als die 3–5%, die man sonst so bekäme, ist logisch.

Dem Lob an die Undsoversity-Macher schließe ich mich uneingeschränkt an, allerdings mit dem persönlichen Nachsatz: Die Verlage, mit denen ich bei bisher als Autor oder Fachgutachter bei verschiedenen Projekten zusammengearbeitet habe, legen großen Wert auf die inhaltliche Qualität und deren Kontrolle. Es ist schön, wenn die gesteigerte Effizienz zu höheren Einnahmen der Autoren führt – reich wird mit Fachbüchern oder Videotrainings nämlich niemand. Aber die Qualität der Produkte sollte in keinem Fall leiden, denn im Direktvertrieb ist eben auch direkt und ausschließlich die eigene Reputation in Gefahr. Deshalb meine Empfehlung an Gerrit: die Schwachstellen identifizieren und den Workshop überarbeiten.

Ich weise darauf hin, dass sich meine Meinung ausschließlich auf die drei Probekapitel des deutlich umfangreicheren jQuery-Workshops stützt und die hier formulierte Kritik auch nur diese drei Kapitel betrifft. Zu den weiteren 15 Kapiteln kann ich nichts sagen, denn gekauft habe ich den Video-Workshop nicht.