Mittwoch,
12. Juni 2013

Das Warten ist endlich vorbei. Heute am frühen Morgen (7:50 Uhr Ortszeit) hat die Version 4.1 von YAML das Licht der Welt erblickt. Für mich endet damit mehr als nur eine 6 monatige Entwicklungszeit, doch dazu mehr am Schluss dieses Beitrags. Zunächst möchte ich die neue Version vorstellen und ein wenig über die Hintergründe erzählen.

Github

Die Projektdateien von YAML liegen ab sofort auf Github. Über viele Jahre habe ich YAML in einem privaten SVN Repository gepflegt und bin damit als Einzelentwickler auch sehr gut gefahren. Doch auch wenn SVN ein, zwei wirklich liebenswerte Features hat, ist Git ein großes Stück anwenderfreundlicher, weshalb ich bei anderen Projekten schon seit Jahren mit Git arbeite. Der Umstieg bei YAML war dennoch nicht ganz einfach, weil ich lange mit mir gerungen habe, in wie weit die Versionsgeschichte aus dem SVN Repro in das Git-Projekt herüber gerettet werden sollte – schließlich geht es um mehrere Jahre nachvollziehbarer Entwicklungsarbeit. Letztlich führte eine Entscheidung an anderer Stelle dazu, dass diese Gedanken hinfällig waren und ich mit einem mehr oder minder frischen Repro gestartet bin, und zwar die, YAML 4.1 auf dem im Herbst letzten Jahres veröffentlichten Sass-Port von YAML 4.0.2 aufzubauen.

Sass

YAML 4.1 basiert vollständig auf Sass. Ich beobachte die Entwicklung bei CSS-Präprozessoren schon über eine sehr lange Zeit, dennoch hat sich meine Meinung zu ihnen erst im Verlauf der letzten 12 Monate nachhaltig verändert. Angefangen hat alles mit einem Website-Projekt, welches ich gemeinsam mit Jens Grochtdreis durchgezogen habe und bei dem ein sassifiziertes YAML aus Jens eigener CSS-Werkstatt zum Einsatz kam. Die Einfachheit der Pflege und die Möglichkeiten der Modularisierung in Verbindung mit Variablen und den damit einhergehenden Konfigurationsmöglichkeiten für den CSS-Code waren einfach zu verlockend. Deswegen habe ich im Herbst letzten Jahres damit begonnen, den zuvor bereits angesprochenen Sass-Port von YAML zu erstellen. Und seither gab es eigentlich kein Zurück mehr, denn ich möchte den Komfort dieser Arbeitsweise nicht mehr missen.

Dennoch habe ich mich schwer damit getan, die Codebasis von YAML vollständig auf Sass umzustellen. Dies hat gleich mehrere gewichtige Gründe. Erstens ist Sass zwar hipp und in Entwicklerkreisen mittlerweile weit verbreitet. Dennoch ist es aus meiner Sicht auch heute nur ein kleiner Bruchteil der Webentwickler, die Präprozessoren in ihren Arbeitsalltag aufgenommen haben. Zweitens ist die Arbeit mit einem Präprozessor nur dann sinnvoll, wenn alle im Team damit arbeiten können. Damit ist Sass auch heute nicht für jedes Projekt und jedes Entwicklerteam geeignet. Und letztlich hinkt bis heute die Entwicklung der Developertools der Browser hinterher, denn von Präprozessoren kompiliertes CSS lässt sich nach wie vor nur vergleichsweise mühsam debuggen. Source-Maps könnten hier nachhaltig für Erleichterung sorgen, allerdings ist der Support für Source-Maps in den Developer-Tools, wie auch bei den Präprozessoren selbst noch “in den Kinderschuhen” bis “nicht vorhanden”, sodass echte Hilfe sicher eine Weile auf sich warten lässt.

All diese Gründe haben mich nach einer Projektstruktur suchen lassen, die einerseits mir ermöglicht YAML mit Sass zu entwickeln sowie Sass-willigen Anwendern einen möglichst gut konfigurierbaren Sass-Port des Frameworks bereitzustellen, andererseits aber der Masse der YAML-Anwender aber auch weiterhin uneingeschränkt die Möglichkeit zu geben, mit YAML als reinem CSS-Framework zu arbeiten. Diese Suche ging verständlicherweise nicht ohne Diskussion mit Sass-Usern und einigen Sackgassen verbunden, doch ich denke, diese Arbeit hat sich gelohnt. An dieser Stelle vielen Dank an Jens Grochtdreis (@flocke) und Michael Schulze (@michsch) für die zahlreichen Anregungen. Die in YAML 4.1 realisierte Projektstruktur erlaubt beiden Anwendergruppen einen schnellen Projekteinstieg.

Einen weiteren Vorteil des eingeschlagenen Weges sehe ich in der Aufrechterhaltung der Modularität des Frameworks bei der klassischen Arbeit mit CSS-Dateien. Aktuell in den Himmel gehobene CSS Frameworks wie Bootstrap oder Foundation leiden meiner Ansicht nach darunter, dass die Modularität des Frameworks in die Präprozessor-Ebene verlagert wurde. Das Standard-CSS dieser beiden exemplarisch genannten Frameworks umfasst jeweils ca. 100 bis 120kB CSS in einer einzigen Datei, weitgehend ohne strukturierende und erklärende CSS-Kommentare. Auf CSS Ebene ist es daher nahezu unmöglich, einzelne Komponenten herauszulösen oder wenigstens sie bei Nichtbenutzung auszublenden.

Grunt

Ein wichtiger Baustein bei der eben beschriebenen Lösung, dem Anwender beide Workflows zugänglich zu machen, war der Einsatz von Grunt, um aus dem Sass-Projekt heraus die CSS-Dateien und des YAML Frameworks zu erzeugen. Über den Sass-Port von YAML wird es damit möglich, YAML individuell zu konfigurieren und daraus mittels Grunt im Handumdrehen ein individuell angepasste CSS-Dateien für YAML zu erzeugen. Quasi als Abfallprodukt ist es mit Grunt auch ein Leichtes, den Namespace (“ym-” Präfix der Klassennamen) der YAML-eigenen CSS-Bausteine zu anzupassen oder völlig zu entfernen. Auch hier ist das Schöne daran, dass kein Anwender gezwungen ist, sich mit Grunt auseinanderzusetzen. YAML funktioniert ganz genauso wie bisher. Allerdings werden mit YAML 4.1 eine Reihe komfortabler Werkzeuge mitgeliefert, um sich bei Bedarf und Interesse das Framework gemäß den eigenen Wünschen und Erfordernissen automatisiert anzupassen.

Änderungen am Core

YAML 4 bringt endlich wieder ein vollständiges Changelog mit, welches über alle Änderungen informiert. Die größten inhaltlichen Änderungen an YAML hat das Formularmodul, sowie das zugehörige Theme erfahren. Das Ziel der Überarbeitung war, endlich eine standardisierte Lösung für die Anordnung mehrerer Formularelemente innerhalb einer Zeile zu finden. Ein weiteres Ziel bestand darin, die Spezifität der Selektoren herunterzusetzen, sodass das Überschreiben der Vorgaben des Frameworks für den Anwender einfacher wird. Daneben wurden bei den Buttons zwei bisher fehlende Dinge ergänzt: Es gibt nunmehr mehrere Größen als auch unterschiedliche Buttonfarben für unterschiedliche Zwecke.

Die Erarbeitung der Gridlösung für Formularelemente erforderte zwangsläufig auch eine saubere Trennung zwischen CSS-Klassen, die für das Formulardesign zuständig sind und denen, die strukturelle Aufgaben übernehmen. Gemeint sind hier die ym-fbox-[x] Klassen der Adressierung der Formularelemente im IE6 dienen und als solche fortan keine Layoutaufgabe mehr haben und werden nur noch dann benötigt, wenn ein vollständiger IE6 Support im Projekt benötigt wird. Das Markup der Formulare wird durch diese Regelung nun etwas übersichtlicher und einfacher.

Umgang mit alten Browsern

Die Unterstützung älterer Browser, soweit sie technisch dazu in der Lage sind, die gestellten Layoutaufgaben zu erfüllen, war stets eines der Kernaufgaben von YAML. In Deutschland und vielen anderen Ländern kann man davon ausgehen, dass der Support des IE6 bei der Projektentwicklung weitgehend eingestellt ist und auch die Unterstützung des IE7 langsam rückläufig ist. Letztlich hat Microsoft mit dem Pflichtupdate für Windows XP dafür gesorgt, dass der IE8 sich als neue untere Supportschwelle etabliert.

Gleichzeitig werden von einem zeitgemäßen CSS Framework nicht mehr nur die Lösungen einfacher Layoutaufgaben gefordert, sondern zusätzlich ein reibungsloses Zusammenspiel modularer UI Bausteine in einem responsiven Umfeld. Dieser Aufgabe auf effektive Weise gerecht zu werden, verlangt an vielen Stellen auch den Einsatz aktueller Webtechniken (und aktuell meint dabei: weniger als 5 Jahre alt). Dieser Anspruch beißt sich bei der Weiterentwicklung von YAML mehr und mehr mit der Unterstützung veralteter Browser.

Aus diesem Grund habe ich mich entschieden, dass die aktuelle Version 4.1, einschließlich eventueller Releases zur Codepflege (4.1.x) die letzte Version von YAML 4 sein wird und gleichzeitig die letzte YAML-Version, die sich den IE6 und IE7 Support auf die Fahnen schreibt. Damit sollte es auch keine Überraschung sein, wenn ich hier sage, dass die Arbeiten an YAML 5 hinter den Kulissen bereits begonnen haben und diese Version den IE8 benötigen wird. Zwar gibt es bereits heute CSS Frameworks, die sogar den IE9 als Untergrenze voraussetzen, das widerspricht jedoch der aktuellen Browserlandschaft, in welcher der IE8 nach wie vor nicht zu vernachlässigende Zugriffszahlen hat.

Um Fragen nach dem zu erwartenden Release von YAML5 gleich zu beantworten: Es existiert noch kein Code. Es dauert also noch ein Weilchen. Wohl aber formt sich aus vielen Ideen und Erfahrungen der letzten Jahre gerade ein Konzept und der Startpunkt für die Realisierung dieser Ideen ist in Sichtweite.


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.