Es wird noch lange eine Herausforderung bleiben, für Progressive Enhancement zu werben. Also dafür, dem Browser das zu geben, was er kann und nicht mehr. Wir haben uns selber in diese missliche Lage gebracht, weil wir jahrelang Wege gesucht und gefunden haben, anspruchsvolle Designs auch für den IE zu realisieren. Unsere Kunden wissen also, daß wir Wege finden werden, alle Details browserübergreifend zu realisieren. Wir sollten dazu übergehen, die Aufwände zu spezifizieren, die eine moderne und eine IE-spezifische Lösung bedeuten.

Vor kurzem habe ich in einem kleinen Team an einem Projekt gearbeitet, dessen Frontend sich durch viele runde Ecken, Verläufe und Schatten auszeichnete. Diese runden Ecken mit Schatten mußten sich zudem auch über andere Boxen legen können. Da es sich um eine Intranet-Anwendung handeln wird, konnten wir von einer extrem hohen IE-Dichte ausgehen. Allein für die unterschiedlichen runden Ecken, mit und ohne Schatten, hat ein Kollege mehr als einen Tag benötigt, um alle Grafiken in Sprites vorzubereiten. Hinzu kamen meine Aufwände, die richtige Struktur zu finden. Hätten wir alles nur mit CSS3 realisiert, wären wir nach einer halben Stunde fertig gewesen. Den Zusatzaufwand kann man in Euro ausdrücken. Die mit der grafischen Sonderlösung zusammenhängende Performanceverschlechterung hat nachher auch finanzielle Folgen und sie verschlechtert die Nutzerfreundlichkeit.

Vielleicht tragen Apples Kult-Geräte iPod, iPhone und iPad ja dazu bei, daß ein Umdenken entsteht. Auf diesen Geräten laufen keine Internet Explorer. Hier kommt mit Safari ein Webkit-Browser zum Einsatz. Apple ist dabei, immer neue Spielereien zu entwickeln, die sie in ihren Browser implementieren. So wie Microsoft dies früher auch tat. Möchte man nun also seine Seite “für das iPad optimieren” und geht man dabei den alten, traditionellen Weg, muss man entweder alle neuen Apple-Spielereien für alle anderen Browser mittels Javascript nachbauen oder eine separate Webkit-Version einer Webseite erstellen. So oder so, es endet in einer Wartungshölle.

Chris Heilmann zeigt in einem Artikel bei Microsofts “Script Junkie”, wie man praktisch mit “Progressive Enhancement” zum Erfolg kommt. Ich stelle in meinem ersten Artikel bei “Create or Die” ein paar Seiten vor, mittels derer man CSS3 austesten und sich Code ausgeben lassen kann. So kann jeder mal “reinschnuppern”.

Wir müssen damit rechnen, daß der IE6 noch ein paar Jahre mit hohen Zugriffszahlen existieren wird. Aus der Sicht einer performanceorientierten, sparsamen Erstellung von Webseiten ist es aber egal, ob der IE6 stirbt oder nicht. Erst ab dem IE9 wird die Sache für uns interessant. Die IE-Versionen 7 und 8 müssen also auch erst von der Bildfläche verschwinden, bis wir nicht mehr genötigt sein werden, Krücken zu nutzen. Das wird viele Jahre dauern, denn die Beharrungskräfte sind sehr stark, wie die Antwort der Britischen Regierung auf eine Petition gegen den IE6 in Behördennetzwerken zeigt. Die Regierung will weiterhin auf den IE6 bauen. Zum einen glauben sie, eine adäquate Sicherheit auch über Firewalls erzeugen zu können und verweisen dann darauf, daß es zuviele interne Applikationen gibt, deren Funktionsweise mit anderen Browsern nicht gewährleistet ist. Ein Test wäre zu aufwändig und teuer. Chris Heilmann analysiert die Argumentation sehr detailliert und fundiert. Sein Artikel ist ein wichtiges Dokument, um sich unser Dilemma vor Augen zu führen. Denn obwohl es sich um die Britische Regierung handelt, wird sich deren Argumentation nicht stark von Firmen und Behörden in Deutschland unterscheiden.

Das Dilemma ist relativ einfach: Aus Sicht der Britischen Regierung (und der meisten Firmen) sind die Browser für die Nutzung des Intranets und internen Tools da. Die private Nutzung des Internets wird mehr oder minder geduldet. Es ist aber nicht die Aufgabe der Regierung oder einer Firma, für eine bessere Nutzung von Google Maps, eines Reiseportals oder von GoogleMail zu sorgen, wenn dies nicht im Behörden-/Firmeninteresse geschieht.

Es gibt aber nicht zu ignorierenden Nutzungsspitzen während der üblichen Bürozeiten. Deshalb sind die meisten Anbieter im Netz daran interessiert, auch den Nutzern aus Behörden- und Firmennetzwerken eine angenehme und moderne Webseite zu präsentieren. Es wird schwer, dagegen zu argumentieren. Aber ich gebe die Hoffnung nicht auf, daß spätestens eine detaillierte Auflistung der Sonderaufwände für den IE und die damit verbundenen Kosten ein Umdenken hervorbringt.

Gerne werden Javascript-Lösungen propagiert, die dem IE runde Ecken und mehr beibringen sollen. Meine Erfahrungen damit sind nicht berauschend. Ich rate davon ab, runde Ecken mittels Javascript zu erzeugen. Richtig schlimm sind Skripte, die transparente PNGs im IE6 ermöglichen sollen. Sie ziehen die Performance extrem in den Keller.
ich finde es wichtig, ein Layout von Beginn an als Ideal zu definieren, das in manchen Browsern nicht erreicht werden wird. Der IE ist nunmal wie ein schwarz-weiss Fernseher: Man kann damit Farbfilme sehen, sie werden aber anders dargestellt und das richtige Vergnügen stellt sich erst mit einem Farbfernseher, also einem modernen Browser, ein. Wenn wir dies immer mehr Kunden und Kollegen begreiflich machen können, werden wir unsere Freude mit CSS3 haben. Wenn nicht, wird es ein Haufen Arbeit, zweigleisig zu fahren.

Die Kurzreferenzen bieten zudem immer einen kompakten Einblick in die Materi. Das habe ich schon bei den Ausgaben zu CSS und PHP zu schätzen gewußt. Bei jQuery – kurz & gut
von Andreas Vdovkin ist auch wieder der Einstieg gut gelungen. Auf wenigen Seiten erklärt er ein paar Javascript-Grundlagen, wichtige Programmiertechnik-Aspekte von jQuery sowie das Konzept des unaufdringlichen Javascript.

Das sind in ihrer inhaltlichen Tiefe und Ausdehnung nur Vorgeplänkel, aber durchaus wichtige Zusatzinformationen, um jQuery als solches besser verstehen und einordnen zu können. Den weitaus größten Teil der knapp 160 Seiten nimmt eine Referenz ein. Im ersten Kapitel geht der Autor von der Frage, wie man jQuery einbindet über das Chaining zu Queues und Speicherfunktionen. Die eigentlichen Bestandteile des Frameworks werden in Kapiteln abgehandelt, deren Überschriften sich mir nicht immer intuitiv erschlossen. Die Selektoren, die große Stärke von jQuery, werden verwirrenderweise unter “Suchen” subsummiert.

In den Kapiteln werden die einzelnen Methoden von jQuery kurz und verständlich mit jeweils einem kleinen Beispiel erklärt. Man muss allerdings wissen oder erahnen, in welchem Kapitel man Hilfe bekommt. Es fehlt eine Übersicht, welche Methoden sich in welchem Kapitel befinden und umgekehrt, welches Kapitel welche Methoden beinhaltet. Das Register ist leider wenig hilfreich.

Für die tägliche Arbeit am Rechner ist dieses Buch sicherlich unpraktisch, obwohl es sich besser lesen lässt, als die offizielle API. Ich finde es sehr hilfreich, um sich abseits des Rechners mit jQuery zu beschäftigen. Zudem kann man beim Lesen des Buches immer wieder auf Ideen kommen. Der einzige richtige Haken des Buches ist, daß es auf der Version 1.3.2 des beliebten Frameworks beruht. Ich hoffe, daß Autor und Verlag noch dieses Jahr mit einer zweiten Auflage auf den Markt kommen, in der die Neuerungen der Version 1.4 ihren Niederschlag finden. jQuery ist in ständiger Weiterentwicklung, das ist gut für uns Entwickler und schwierig für Buchautoren. Das Büchlein finde ich als Ergänzung zu einem richtigen jQuery-Buch oder als nette Offline-Variante der API sehr empfehelenswert.

Steglich unterteilt sein Buch in 9 Kapitel. Darin widmet er sich u.a. dem Termindruck als allgemeinem Phänomen, der Aufgaben- und Terminverwaltung, der Akquise, der Projektplanung und weiteren Phasen unseres Tuns. Der Autor macht dabei nie den Eindruck, als wolle er den Leser bevormunden, ihm einen Arbeitsstil aufzwingen. Ich hatte immer den Eindruck, der Autor wisse genau über meinen Alltag Bescheid, als sei er ein Kollege. Seine Schlussfolgerungen klingen logisch. Seine Empfehlungen sind teilweise bekannt, wenn man sich ein wenig mit Zeitmanagement am und mit dem Computer beschäftigt hat.

Sehr schön und wichtig finde ich, daß Steglich immer wieder auf Tools hinweist, sie aber weder als Allheilmittel noch als Selbstzweck begreift. Nicht alle seine Tips laufen auf die Verwendung von Tools oder irgendwelchen Listen hinaus. Er diskutiert auch die Zeitersparnis durch Entwicklungsframeworks oder die Bedeutung eines schnellen Telefonanrufs.

Der Autor behandelt die Themen kurz und knapp. Man hat aber nie den Eindruck, etwas Wichtiges würde fehlen. Durch die fehlende Geschwätzigkeit ist das Buch auf den Punkt konzentriert und leicht lesbar. Es empfiehlt sich, das knapp mehr als 200 Seiten starke Buch in Abständen mehrmals zu Rate zu ziehen. Eine effektive und gute Arbeitsorganisation kann nicht das Ergebnis eines einmaligen Lesens sein. Es ist vielmehr das Ergebnis eines ständigen Optimierungsprozesses. Das Buch hilft bei diesem Prozess sehr gut weiter. Denn es holt GTD in die Niederungen der Arbeitswelt eines Webentwicklers. Für diese, egal ob selbständig oder angestellt, kann das Zeitmanagement-Buch von Thomas Steglich eine prima Hilfe sein.

Das WordCamp2010 in Berlin war als eintägige Veranstaltung organisiert. Eine ungewöhnliche Sache, vor allem wenn man berücksichtigt, daß der Veranstaltungsort Berlin zwar immer zieht, für die meisten Besucher aber doch sehr abseits liegt. Eine Anreise am Vortag ist eigentlich immer geboten. Durch ein zwangloses Kennenlernen-Treffen im Brauhaus-Mitte war das für jeden auch ein Gewinn. Aber der Sonntag hinterließ ein seltsames Gefühl. Es fehlte einfach der zweite Tag.

Die Organisatoren riefen mehrfach dazu auf, Sessionvorschläge schon frühzeitig auf der Webseite anzukündigen. Aus den Vorschlägen wurde dann ein vorläufiger Sessionplan gezimmert. Das ist eine prima Sache, um sich inhaltlich einzustimmen und um eventuell den Chef zu überzeugen, daß ein Besuch eine gute Idee wäre. Denn will man sich eine Konferenz bezahlen lassen kommt es immer besser, mit konkreten Plänen zu winken als mit der Idee, daß sich alles schon von selber gut regulieren werde. Die Vorläufigkeit dieses Plans hatte aber offenbar nicht jeder verstanden, denn Michael Jendryschik wurde von einem Teilnehmer auf das Übelste beschimpft, weil er seine Session um eine Stunde verlegte, um nicht gegen Vladimir Simovic anzutreten, dessen Session ihn selber interessierte. Da hatte jemand offenbar die Dynamik eines Barcamps nicht begriffen.

Die Sessions

Der Tag begann für mich mit einer Session von Vladimir Simovic. Er sprach über Performancebremsen bei Wordpress-Blogs. Anfangs dachte ich, ich würde zum wiederholten Male die allgemein bekannten Erkenntnisse hören. Doch recht schnell schwenkte Vlad von den allgemeinen Regeln zu sehr spezifischen Erkenntnissen um. Immer mit einer Prise Humor gab er viele praxisrelevante Tips. Ich hoffe sehr, daß er die Überarbeitung seiner Folien bald fertig hat, daß er sie öffentlich zur Verfügung stellen kann. Bis dahin lohnen sich auch seine Blogartikel über Performance.

In der nächsten Session sprach Michael Jendryschik über media-queries. Ein sehr neues und sehr interessantes Thema, dem wir uns sicherlich in nicht allzu ferner Zukunft häufiger widmen werden. Auch wenn die IEs bis inklusive Version 8 mit media-queries nichts anfangen können, sind sie doch eine prima Möglichkeit, um modernen Browsern und vor allem Browsern auf Smartphones kontextabhängige Styles zu liefern. Die gewählten Beispiele waren klasse und haben Lust auf eigene Experimente gemacht.

Vor der Mittagspause ließ ich mir von Thomas Boley seine Template-Engine TempELA erläutern. Gedacht ist die Engine nicht für ganze Themes, sondern für Plugins und Widgets. Sein Bestreben nach sauberem Code kann ich natürlich nur unterstützen.

Nach dem Mittagessen gab uns Sylvia Eggerts Session eine Analyse des Stands der Barrierefreiheit im aktuellen Wordpress 3.0-Standardtheme. Man kann ihre Erkenntnisse wohl so auf den Punkt bringen: das neue Theme führt die Barrieren des alten fort. Das Theme weist wenige Barrieren auf, aber an den Farbkontrasten wie an der Visualisierung der Tastaturnutzung könnte noch gearbeitet werden. Alles in allem finde ich die Ausgangslage aber richtig gut.

Bevor das WordCamp zu Gunsten des WM-Spiels gegen Argentinien unterbrochen wurde, wohnte ich noch der Session von Michael Preuß bei. Michael zeigte sein Theme-Framework, das auf Basis von YAML entstanden ist und ab Wordpress 3.0 laufen wird. Ich bin sehr gespannt darauf, es zu testen. Mit Hilfe dieses Frameworks kann man sich sein YAML-basiertes Layout im Prinzip im Backend zusammenstellen. Selbst wichtige Plugins liefert Michael in eigener Machart mit. Das Framework hat nicht nur mich, sondern auch den neben mir sitzenden YAML-Vater Dirk Jesse so begeistert, daß wir über die Diskussion mit Michael den Anstoss des Spiels ignorierten. Das erste Tor konnten wir so nur in der Wiederholung bejubeln.

Nur ein Tag

Das WordCamp 2010 war als eintägige Veranstaltung konzipiert. Das ist sehr schade. Die meisten werden von weither gekommen sein – Berlin ist schließlich am Rande Deutschlands – und hätten einen zweiten Tag gut nutzen können. Denn eine Übernachtung war ja sowieso drin. Aber auch das Thema gibt viel Stoff her und ein zweiter Tag, vielleicht sogar mit Praxisworkshops, wär sinnvoll und schnell gefüllt gewesen.

Die Location

Ich war sehr gespannt, als ich hörte, wir würden in einer Coworking-Area tagen. Das Konzept finde ich klasse und habe auch schon einiges über die Frankfurter Coworking-Area gehört. Ich hoffe, nicht alle Coworking-Areas sind so, wie das Betahaus. Das Gebäude hatte den Charme eines vor etwa 20 Jahren verlassenen Lagerhauses, das notdürftig von ein paar Hausbesetzern wieder hergerichtet wurde. Für die Tagung selber war mir das allerdings herzlich egal.

Allerdings fehlten in den oberen Räumen und im Foyer eindeutig Mikrofone und Lautsprecher. Die Vorstellung der Sessions war bei mieser Akkustik und zu lauten Teilnehmer größtenteils gar nicht zu verstehen. Bei Vlads Session hätten die doppelte Anzahl Stühle stehen dürfen. Platz wäre genug gewesen. Der Verzicht auf Tische führte zumindest dazu, daß sich weniger Menschen nebenbei noch am Rechner betätigten.

Verpflegung

Ein Barcamp und so auch das WordCamp ist eine kostenlose Veranstaltung. Dementsprechend schraube ich meine Erwartungen niedrig. Zwar hatten meine letzten Barcamps alle eine geniale Verpflegung morgens und den ganzen Tag über, aber ich erwarte dies nie. Das WordCamp bot kein Frühstück, also nahm ich das meines Hotels in Anspruch. Allerdings hätte es etwas Leckeres im Betahaus gegeben. Es wurde leider verabsäumt, dies zu kommunizieren. Ich hätte lieber dort als in meinem Hotel das Geld gelassen.

Etwas ungünstig war die Verpflegungssituation in der Mittagszeit. Der Schnell-Vietnamese, den ich mir mit anderen aussuchte war lecker, aber nicht schnell und etwa 5 Minuten Fußweg entfernt. So kam ich mindestens 10 Minuten zu Sylvias Vortrag zu spät.

WLAN

Die Versorgung mit Internetzugängen ist auf Barcamps immer wieder ein leidiges Thema. Da ich meinen Surfstick im Hotel vergessen hatte, betraf die Unterversorgung auch mich. Es gab einige wenige Glückliche, die von Anfang an Internetzugang hatten. Im Laufe des Tages sollte sich die Lage gebessert haben. Mich interessierte das nicht mehr. Ich stellte fest, daß es viel mehr Spaß macht, den Vortragenden zuzuhören und mit ihnen zu sprechen, als dauernd zu twittern.

Diskussionsfreudigkeit

Alle von mir besuchten Sessions wurden immer wieder von Fragen und Bemerkungen der Teilnehmer bereichert. So sollte es sein, es sollte ein offener Dialog entstehen. Ich fand diese Offenheit und das Engangement aller Teilnehmer sehr angenehm und bereichernd.

Sessionplan

Anfangs wurde der immer aktuell gehaltene Sessionplan auf die Wand im Foyer per Beamer geworfen. Dank des schlechten WLANs war dies für die meisten die einzige Möglichkeit, auf den Plan zuzugreifen. Vier von fünf Räumen befanden sich im vierten Stock. Dort gab es aber leider keinen Plan. Der Aufzug wiederum war sehr langsam und es gab für alle 200 Teilnehmer auch nur diesen einen Aufzug. Nach einer Session herunterzufahren oder zu laufen um danach dann wieder den Weg zurück anzutreten ist aber keine tolle Idee.

Nach dem Mittagessen wurden im Foyer die Stühle für die Fußballübertragung aufgebaut und der Beamer wurde für das Fernsehbild eingerichtet. Dadurch gab es nach dem Mittagessen keinen Sessionplan mehr für mich. Das war sehr bedauerlich.

Fazit

Ich habe viele Kleinigkeiten gelernt, habe ein paar interessante Menschen kennengelernt oder wiedergetroffen. Deshalb wäre ich bei einem erneuten WordCamp dabei. Egal wo es stattfinden wird, abgeterennte Räume mit nicht allzu schlechter Akkustik und zusätzlich Mikrofon/Lautsprecher sollten drin sein. Das WLAN sollte genügend Nutzer vertragen und der Sessionplan auch mal in nicht-digital vorliegen, damit man nicht von Strom, Rechner, Internetzugang und Beamer abhänging ist

Ich werde demnächst ein Gutachten für einen Kunden verfassen, in dem ich die Barrierefreiheit einer Webseite beurteilen soll. Streng genommen müßte ich dies nach der geltenden BITV tun. Doch die war schon zum Zeitpunkt ihrer Veröffentlichung vor fast zehn Jahren veraltet. Heute ist sie nur noch ein Relikt aus alten Tagen. Ich habe mich mit dem Kunden auf die BIENE-Prüfschritte als Bewertungskriterien geeinigt. Denn am Ende ist es unwichtig, ob es die BITV gibt oder nicht. Am Ende ist es nur wichtig, daß eine Seite zugänglich ist. Die BITV ist hierfür schon lange kein sinnvoller Maßstab mehr, sondern eher ein Hemmschuh. Deshalb sollte sie endlich durch etwas Neues ersetzt werden. Dieses Neue sollte am Besten die WCAG2 sein, denn die in Deutschland zuständigen Stellen haben nun schon zwei Jahre lang ihre Überforderung demonstriert. Es reicht.

Es war klar, daß so ziemlich jeder unter “die Pest” den IE verstehen würde. Der war durchaus mit gemeint. Hauptsächlich spielte ich allerdings auf das Buch “Die Pest” von Albert Camus an. Seine Philosophie spielte auch mit der Sage von Sisyphos, das war mein Ansatzpunkt. Doch ich denke, die Folien sprechen im wesentlichen für sich selbst.

• extra Element für die Transparenz, das absolut positioniert wird
• Nutzung von RGBa und einem IE-Filter

Glücklicherweise entscheiden sich mehr und mehr Kunden dafür, daß eine Seite nicht mehr in jedem Browser gleich aussehen muss und dass man weniger Rücksicht auf den IE6 nehmen sollte. Deshalb habe ich gerade in einem Projekt einen halbtransparenten Container mit der zweiten Methode erstellt.

Doch diese Methode hat ihre Tücken. Für den IE vergeben wir einen Wert, der eine Kombination aus Farbe und Transparenz ist. Der Transparenzwert ist dabei die hex-Umrechnung des normalen Zahlenwertes. Doch wie komme ich an den hex-Wert?

Robert Nyman beschreibt eine Methode, die schnell in Firebug funktioniert. In der dortigen Konsole gibt man eine kleine Zeile Javascript ein. Zur Umrechnung eines 30%igen Transparenzwertes (opacity: 0.3) lautet die Zeile:
Math.floor(0.3 * 255).toString(16);


Seit Jahren werbe ich immer wieder für die Nutzung von YAML. Nicht, weil ich dafür Geld bekäm, sondern weil ich die Nutzung eines Frameworks für sinnvoll erachte und YAML für das Beste der derzeit existierenden halte. YAML wird dabei immer wieder vorgeworfen, es sei so “schwer” und habe einen zu komplexen Code. Abwechselnd wird von DIVitis oder DIV-Wahnsinn gesprochen. Ihre dauernde Wiederholung macht allerdings diese Behauptungen nicht wahrer. Die Kritiken zeugen in meinen Augen davon, daß das Konzept von YAML nicht verstanden wurde.

YAML bietet von Anfang an erst einmal alles. Der Trick besteht darin, das Unnötige wegzunehmen. So gehe ich auch in meinem Entwicklungsframework vor. Ich kann gut verstehen, daß das gewöhnungsbedürftig ist. Die Alternative wäre, eine ganz grobe Vorlage zu haben, in die man dann die benötigten Einzelteile einfügt. Das liefert mir prinzipiell jeder gute Editor, dafür brauche ich kein Framework. Zudem benötige ich einen Ort und eine Ordnungsmethode, um meine hinzuzufügednen Einzelteile zu finden und dann in meine neu entstehende Webseite einzufügen. Auch in diesem Falle benötige ich eine Art Framework-Grundlage. Ich bevorzuge, alle wichtigen Dateien und Skripte an einem Platz zu haben, so daß ich sie jederzeit anwenden kann, und die unnötigen am Ende schnell zu löschen.

Dirk Jesse schachelt bei YAML alle Layoutcontainer doppelt. Ich denke, es ist dieser Umstand, den viele kritisieren. Doch hinter der Verschachtelung steckt Sinn. Dirk entwickelt YAML immer mit dem Gedanken an flexible Layouts im Hinterkopf. Wenn man dementsprechend einem Container eine Breite in Prozent gibt, kann man ihm schwerlich ein Padding in Pixeln oder em geben. Schachtelt man nun einen Container in den Äußeren, dann gibt der Äußere die Breite vor und der Innere erzeugt über Padding oder Margin Abstände für die dann folgenden Inhalte. Natürlich kann ich auch den inneren Inhalten diese Abstände zuweisen. Doch das bedeutet mehr Schreibarbeit, schlechtere Wartbarkeit und weniger Flexibilität. Über die Verschachtelung ist sichergestellt, daß die Inhalte auf alle Fälle die korrekten Abstände bekommen. Zudem ist es egal, welche Inhalte in den inneren Container geschachtelt werden, sie bekommen immer den richtigen Abstand.

Die meisten Entwickler werden hingegen fixe Layouts mit Pixelbreiten erschaffen. Bei einem fixen Layout wird der innere Container nicht mehr zwangsweise für die Abstände benötigt. In diesem Falle kann man die inneren Container löschen. Das gilt für die Spaltencontainer #col1, #col2 und #col3 genauso wie für die diversen Subcolumns, also die Gridbausteine. Ohne die inneren Container kann man nicht mehr ernsthaft von DIVitits sprechen. Eine Lösung hingegen, in der ich Einheiten für Breiten und Abstände mische, kann ich schwerlich ohne zusätzliche Container lösen. Ich beglückwünsche jeden, der es dennoch geschafft hat. Ich wüßte dann aber auch gerne, ob die Lösung allgemein funktioniert, komplexe Layouts zuläßt und wie lange es gedauert hat, bis man auf sie kam.

Man kann also unter bestimmten Umständen die Struktur straffen. Andere Umstände erfordern hingegen diese verschachtelte Struktur. Denn abseits des Falles eines flexiblen Layouts gibt es genügend Gestaltungsideen, die einen zusätzlichen Container erfordern. Es dürfte schwerlich möglich sein, den Kunden zu erklären, man könne jetzt bedauerlicherweise sein Wunschlayout nicht erstellen, weil man dafür einen semantisch unnötigen Container einfügen müsse.

Ich denke, die Struktur können wir als nicht zu sehr aufgeblasen abhaken. Wie steht es nun mit dem CSS? YAML benötigt zwei Dateien, um zu funktionieren. Jede weitere Datei gehört zum individuellen Layout. Die slim_base.css hat 2,34 KB und hält damit für ziemlich viele Problemfälle Lösungen parat. Wer will, kann sich die Datei noch um die wenigen Einträge kürzen, die er definitv nicht benötigt wird. Man sollte dabei aber wissen was man tut. Angesichts der geringen Dateigröße halte ich eine solche händische Straffung allerdings für albern. Alle IE bis einschließlich Version 7 müssen 5 KB CSS-Dateien laden, da für sie ein separates Patchfile hinzukommt. (Siehe Dirks Artikel über YAML 3.2.)

Ich kann beim besten Willen an diesen Werten nichts Schlimmes entdecken. Die genannten Dateien sind eine Sammlung von Best Practices, an denen man schwerlich vorbeikommen wird. Es ist natürlich etwas Anderes, wenn man solche CSS-Dateien selber zusammensucht. Doch wird dies kaum über einen kurzen Zeitraum geschehen. Man wird seine selbst zusammengestellten Best Practices also nicht zwangsweise besser kennen, als man die YAML-Dateien kennen kann, wenn man sich einmal mit ihnen beschäftigt hat. In meinen Augen unterscheidet sich YAML von den anderen Frameworks dadurch, daß es auf Anwender setzt, die sich mit dem Code auseinandersetzen wollen und können. Es ist nicht einfach nur zum Anwenden da, wie die diversen Grid-Frameworks. YAML will erkundet, erforscht, erobert werden.

Wer sich also mit dem System beschäftigt, wird schnell die Vorteile erkennen. Ich habe mein gesamtes bisheriges Berufsleben meinen eigenen Code geschrieben. Bei meinem letzten Großprojekt für SinnerSchrader habe ich sogar ein eigenes kleines CSS-Framework geschrieben, das uns die Arbeit sehr erleichterte. Dieses war allerdings auf den Nutzungskontext zugeschnitten. Ich genieße es derzeit, daß mir YAML alle Gedanken um das Grundlayout abnimmt und ich mich um die eigentlichen Problemfälle der Entwürfe kümmern kann, von denen es noch genügend gibt.

Die Nutzung eines Frameworks hat für mich im wesentlichen folgende Vorteile:

• Ich kann mich auf Designdetails konzentrieren, weil die groben Probleme browserübergreifend schon gelöst sind.
• Für alle grundlegenden Seitenelemente gibt es eine festgelegte Notation, sodaß ich mir persönlich weder eine eigene ausdenken muss, noch die Gefahr habe, in ein paar Jahren meinen Code nicht mehr spontan zu verstehen.
• Durch die einheitliche Notation können Fremde meinen Code leichter verstehen und meine Arbeit übernehmen.
• Dadurch wird auch die Arbeit im Team stark erleichtert.
• YAML kommt mit einer ausführlichen Dokumentation. Jedes meiner Projekte hat nun also eine Basis-Dokumentation.
• Über allem steht in meinen Augen die Effizienz. Mit einem Framework erstellter Code ist effizient, denn viele Gedanken und Fehlersuchen erübrigen sich. Die Ersparnis ist nicht nur Zeit, sondern bares Geld.

Die Sorge um unnötige DIV-Container finde ich zudem übertrieben. Ich habe eher den Eindruck, es ist ein vorgeschobenes Argument. Und es wird schwer, solche unnötigen Container immer und überall zu identifizieren. Semantisch sind sicherlich sehr viele DIV-Container sinnlos. Sie machen semantisch da Sinn, wo sie eine Webseite in Bereiche unterteilen. Doch leider ist die Frontendentwicklung kein idealer Ort und wir können Layouts nicht der reinen Lehre nach nur mit CSS-Mitteln bewerkstelligen. Wir benötigen immer wieder zusätzliche DIV-Container, um Layouts zu erreichen. Das kann man kritisieren, outet sich dann aber in meinen Augen als Förderer schlichter Textwüsten.

Viele Seiten sind zudem keine simplen Bloglayouts oder einfache Seiten, die von einer Person für eine andere erstellt werden. Große Seiten werden von einem Redaktionsteam betreut, bekommen Daten von aussen angeliefert, bekommen oft Werbung von aussen eingebunden und sollen vielleicht sogar ein flexibel anpassbares Design haben. Wer all dies bewerkstelligen muss, der ist über das eine oder andere zusätzliche DIV sehr froh, das ihm die Arbeit sehr erleichtert. Die zusätzlichen 11 Byte tun weder dem Entwickler, noch dem Nutzer weh.

In Deutschland haben immer mehr Auftraggeber den zeit- und geldsparenden Effekt von Frameworks begriffen und fragen konkret nach einer Umsetzung mit YAML nach. Das hat für sie den großen Vorteil, daß sie den Frontendcode von anderen Entwicklern einfacher warten lassen können, wenn sie es aus welchen Gründen auch immer wollen. Ich sehe derzeit keine Veranlassung, wieder zu meinen alten Methoden zurückzukehren und meinen Code komplett selber zu schreiben.