Weblog

Es ist nicht so, dass es beim Blick auf den Quelltext von Toast nichts zu sagen gäbe. Da wäre zum einen, dass Toast eben nicht, wie fälschlich bei T3N geschrieben, mit einem Standard-Reset daherkommt. Stattdessen setzt man nämlich, und das ist zumindest lobenswert, auf Normalisierung, statt auf Eric Meyers CSS-Dampfwalze, die oft genug in der Kritik stand.

Ein weiteres erwähnenswerte Detail ist der Umstand, dass Toast für seinen flexiblen Grid-Ansatz mal eben auf eines der mit CSS3 neu eingeführten Box-Modelle baut (ohne darauf hinzuweisen, wohlgemerkt). Das macht die Arbeit mit flexiblen Breiten oder unterschiedlichen Einheiten in aktuellen Browsen ausgesprochen angenehm - solange man sich nicht um den Internet Explorer 6 und 7 kümmern muss. Denn diesen dürfte das Grid bei Verwendung irgendeines horizontalen Padding oder Border-Eigenschaft um die Ohren fliegen. Das muss man nicht zwingend negativ sehen, erwähnenswert ist es aber schon (zumal die Codebasis überschaubar ist). Ich persönlich mag da altmodisch denken, aber innerhalb eines Frameworks, halte ich das auch heute mindestens für problematisch, denn die Folgen in alten Browsern können drastisch ausfallen.

Ebenfalls wäre durchaus diskussionsbedürftig, ob es aus Design-Sicht sinnvoll ist, wenn ein CSS-Framework unter “responsive” nichts anderes versteht, als das Grid unterhalb von 775 Pixeln vollständig zu linearisieren (was im übrigen nicht nur Toast, sondern auch andere Projekte betrifft). Aus meiner Sicht stellt sich beispielsweise die Frage, ob ein CSS-Framework für flexible Layouts überhaupt eine solche fixe Grenze vorschreiben sollte? Denn gerade flexible Layouts funktionieren erst richtig gut, wenn man die einzelnen Abstufungen des Layouts individuell auf dessen grafische Elemente abstimmt und sich nicht sklavisch einer fixen Zahl unterwirft, deren Ursprung vor vielen Jahren seine Relevanz verloren hat.

Alle diese Punkte spricht der Beitrag bei T3N aber leider nicht an. Stattdessen bleibt er oberflächlich und nichts-sagend, denn Statements wie “Toast ist nicht für jedes Projekt geeignet. Textlastige Websites können durch den Einsatz des Frameworks an Übersichtlichkeit und Bedienbarkeit gewinnen.” ist ohne Begründung nichts wert. Das eine oder andere wenig technische Detail oder gar eine kritische Anmerkung zur x-ten Kopie der Kopie des Grid-Ansatzes sind offensichtlich zuviel verlangt. Stattdessen werden einfach die Infotexte der Toast-Webseite abgetippt, übersetzt und nicht gerade subtil bebildert - fertig ist der neue Fachbeitrag und genauso schnell sind die Infomeldungen darüber bei Twitter, Facebook, Google+ untergebracht. Dieses Schema taugt auch für die nächsten 50 CSS-Frameworks, soviel ist klar.

Nun, wir haben im deutschsprachigen Raum leider nur eine sehr überschaubare Anzahl von Magazinen, die sich der Frontendentwicklung widmen. Deshalb ich finde es ehrlich gesagt jammerschade, dass die Jungs von T3N sich nicht mehr die Zeit nehmen, den Inhalt der Beiträge vor dem Schreiben genauer unter die Lupe zu nehmen. Hauptsache raus, die gierige Meute im Social-Network-Zirkus will bespaßt werden. Sorry T3N, ihr macht Euch uninteressant und entbehrlich.

Die Vorgeschichte

Es begab sich im Sommer zu 2009, als ein aufstrebener Webentwickler, ich nenne ihn Herrn X. seine eigene Webseite neu einrichten wollte. Da die eigene Kreativität wohl gerade gemeinsam mit seinem Verstand auf Badeurlaub in der Karibik waren, griff Herr X. von jeglichen Hemmungen befreit in eine der unteren Schubladen des guten Benehmens, setzte seine copy & paste Mütze auf und streifte durchs Internet: Warum sich etwas neu ausdenken, was andere schon so übersichtlich und ansprechend hinbekommen haben? Letztlich sind wir doch eh eine große Familie im Web … und so fand er meine Webseite. Und diese gefiel ihm vom Aufbau und Design so einmalig gut, dass er seine ganz genauso aufgebaut und aussehen sollte. Nur hier und da einige winzige Änderungen – der individuellen Note wegen – ein Tüpfelchen Farbe hier und eine runde Ecke da, ganz dezent natürlich, die Vorlage war für ihn schließlich schon so nahe der Perfektion. Schön auch, dass ich seinerzeit einen längeren Blogbeitrag zu meinen Designentscheidungen verfasst hatte. Das hatte auch Herr X. bemerkt und erwähnenswerte Passagen kurzerhand in den Relaunch-Beitrag seines neuen Layouts übernommen.

Einige Monate später trug es sich zu, dass ich beim Sichten einiger Kommentare zufällig auf der schönen neuen Webseite des Herrn X. landete und dort ein ein selten-klares Déjà-vu erlebte. Das alles hatte ich schon mal gesehen … ja richtig, bei mir selbst. Und weil ich wenig begeistert war, die Mühen meiner Freizeit weitgehend deckungsgleich als das Aushängeschild des "professionell" arbeitenden Herrn X. wiederzuerkennen (einzelne Grafiken flossen sogar in eines seiner Referenzprojekte ein), kontaktierte ich Herrn X. per Skype um ihm mein Unbehagen bezüglich seines Handelns zu verdeutlichen. Herr X. berief sich im weiteren Verlauf auf selektiven Gedächtnisausfall ("Ich weiß nicht, was ich mir dabei gedacht habe.") gab jedoch nach mühsamer Diskussion, wie anders ein eigenständiges Layout denn mindestens sein müsse, letztlich doch nach und beseitigte das Problem weitgehend. Damit war das Thema aus der Welt und die Welt drehte sich langsam weiter…

Schlankerer Framework-Core

Die wichtigste Änderung gleich zu Beginn: YAML besteht nunmehr nur noch aus zwei Kernbausteinen. Die base.css ist das Herzstück des Frameworks und stellt dem Nutzer ein schonendes Browser-Reset, oft benötige CSS-Klassen für die Layouterstellung (Float Clearing, Skiplinks, ect.), die “Subtemplates” als flexible Grid-Bausteine, ein universelles Fallback auf ein dreispaltiges Basislayout und wichtige Vorgaben für eine fehlerfreie Druckausgabe bereit. Über den zweiten Baustein, die iehacks.css werden die älteren Versionen des Internet Explorers 5.x bis 7.0 mit Bugfixes versorgt, die so formuliert sind, dass sie ohne Eingreifen des Anwenders den überwiegenden Teil der CSS-Bugs dieser Browser korrigieren. Der ehemaliige dritte Baustein, die print_base.css ist in der base.css aufgegangen.

Eine Umstrukturierung der medienspezifischen Definitionen innerhalb der base.css ermöglichte weiterhin einige Vereinfachungen der Codebasis, sodass trotz der Erweiterung der Grid-Komponente der gesamte Framework-Core insgesamt fast 600 Byte (ca. 10%) kleiner geworden ist. Mit den Wegfall der print_base.css kann zudem ein HTTP-Request eingespart werden (zumindest, wenn man die finalen Stylesheets nicht zusammenfasst) und in modernen Browsern wie dem Internet Explorer 8, Firefox, Opera, der Safari benötigt der YAML-Core nur noch 2,34 kB (slim_base.css). Ausschließlich die veralteten Versionen des Internet Explorers 5.x – IE 7.0 müssen den vollständige Core mit 5,04 kB laden.

Neue Features & Altlastenentsorgung

Wie mit fast jeder YAML-Version wird auch mit YAML 3.2 der Funktionsumfang des Frameworks leicht erweitert. Die Subtemplates (die Grid-Komponente von YAML) erhält vier weitere Unterteilungen (20%, 40%, 60% und 80%). Selbstverständlich besteht auch hier die Möglichkeit, gleiche Containerhöhen über die Klasse .equalize zu erzwingen. Daneben steht mit einem weiteren Add-on, dem SyncHeight-Plugin für jQuery, eine JavaScript-Alternative für das Erzwingen gleichhoher Container zur Verfügung.

Der Formularbaukasten ist ebenfalls flexibler geworden. So ist die Klasse .yform nicht mehr an das form-Element gebunden, was den Einsatz in Content Management Systemen wie z.B. ExpressionEngine vereinfacht, bei denen der form-Tag automatisch vom CMS generiert wird. Die zusätzliche Darstellungsklasse .full hilft bei Platzproblemen (schmale Formulare) und erzeugt Input-, Select-Felder und Textareas mit voller Breite des umgebenden Elternelementes. Ein neues Layoutbeispiel demonstriert, wie einfach und komfortabel sich mehrspaltige Formulare mit YAML erstellen lassen.

Neben diesen neuen Möglichkeiten, wurden mit diesem Release auch einige Altlasten beseitigt. So wurden die IE-Fixes für die ehemaligen ID’s #page_margins und #page aus der iehacks.css entfernt. Beide ID’s werden seit YAML 3.1 (Januar 2009) in mehrfach verwendbare Klassen umgewidmet. Einen echten Feature-Drop betrifft der Verzicht auf die Möglichkeit, Spaltenhintergründe mit Hilfe der Border-Definition von #col3 zu erzeugen. Zwar ist diese Technik denkbar einfach in der Umsetzung, sie beschwört aber in Verbindung mit den Windows-Kontrastmodi ein Zugänglichkeitsproblem herauf, da in diesen Modi Vordergrund- und Rahmenfarben auf den gleichen Farbwert gesetzt werden, infolgedessen Inhalte mit dahinterliegenden farbigen Rahmen (den simulierten Spaltenhintergründen) z.T. nicht mehr lesbar sind. Erschwerend kam hinzu, dass diese Technik im Internet Explorer ein Anpassung des z-index von #col3 bedurfte, was in seltenen Fällen das Selektieren von Inhalten mit der Maus im Browser blockierte.

Ein oft diskutierter Punkt unter vielen Framework-Anwendern war bisher der Workaround zur Vermeidung seitlich springender, zentierter Layouts im Firefox und Safari durch Erzwingen eines vertikalen Scrollbalkens. Mit der Veröffentlichung der neuen Browsergenerationen Internet Explorer 8, Firefox 3.5, Safari 4 und Opera 10 wurde die bisherige Lösung unbrauchbar und deshalb aus dem Core entfernt. An ihre Stelle tritt eine CSS3-basierte Lösung (overflow-y: scroll), welche nunmehr in den Nutzerstylesheets (basemod.css) verankert ist und somit von jedem Anwender bei Nicht-Gefallen einfach deaktiviert/entfernt werden kann.

Ebenfalls ersatzlos gestrichen wurde das Debug-Stylesheet (debug.css), welches mit der Version 3.0 Einzug in das Framework gehalten hatte. Zu sehr litt die Übersicht bei der Vielzahl der gleichzeitig eingeblendeten Informationen. Die fehlende Konfigurierbarkeit und die umständlichen Handhabung waren ebenfalls nicht vorteilhaft. Mit dem bereits im Febuar 2009 veröffentlichten Codeanalyse-Tool YAML Debug steht YAML-Entwicklern eine deutlich bessere und vielseitigere Alternative zur Verfügung, die mit einem einzigen Klick jedes Layout analysiert.

Handwerkszeug für die Barrierefreiheit

Kein Framework, auch nicht YAML, ist ein Garant für barrierefreie Webseiten. Dennoch zeigt sich mehr und mehr, wie sinnvoll und richtig es ist, Webentwicklern das grundlegende Handwerkszeug innerhalb des Frameworks zur Verfügung zu stellen. In YAML 3.2 wird eine neue Darstellungsmöglichkeit für Skiplinks unterstützt, die ein Überlagern des Layouts für die eingeblendeten Skiplinks ermöglicht und dadurch die sonst üblichen Probleme bei deren Integration beseitigt. Zudem wird für Webkit-basierte Browser ein JavaScript-Fix mitgeliefert, um auch Apple’s Safari und Google Chrome dazu zu bewegen, den Focus auf die angesprungene ID zu setzen.

Ein weiterer Schritt ist die konsequente Einbeziehung von WAI-ARIA. Sämtliche bei YAML mitgelieferte Beispiellayouts wurden mit ARIA-Landmarkroles versehen. Zwar handelt es sich hierbei nicht wirklich um ein Feature des Frameworks (die korrekte Auszeichnung sollte der Webentwicklers vornehmen), dennoch halte ich auch diesen Schritt für wichtig, um als Framework-Entwickler trotz der noch fehlenden Validierungsmöglichkeiten im W3C-Validator die positiven Effekte des kommenden Standards hervorzuheben. Schon heute können alle modernen Browser (einschließlich des IE8) mit WAI-ARIA umgehen und ermöglichen somit einen deutlichen Zugewinn an Barrierefreiheit auf Webseiten jeder Komplexitätsstufe.

Das “Accessible Tabs” Plugin von Dirk Ginader wird mit YAML 3.2 als Add-on ein fester Bestandteil des Frameworks. Das dahinter stehende Konzept habe ich zusammen mit Dirk Ginader bereits vor zwei Jahren entwickelt, die Umsetzung im Rahmen dieses Plugins ist mittlerweile ausgereift und umfangreich getestet. Auch dieser Baustein ist weniger als Feature des Frameworks zu sehen. Stattdessen bemühe ich mich darum, zusammen mit YAML sinnvolle Best-Practice-Lösungen zu vermitteln und die Verbreitung dieser Techniken zu fördern.

Zusammenfassung

Neben diesen großen Neuerungen/Verbesserungen stehen zahlreiche kleinere Korrekturen hier und da, über die das Changelog im Detail Ausfunft gibt. Wie mit jedem Release wurde auch die Projektvorlage “Simple Project” auf den aktuellen Stand gebracht.Der YAML Builder beherrscht momentan WAI-ARIA noch nicht und auch die neue Skiplink-Variante ist dort noch nicht implementiert, die Codeausgabe ist aber selbstverständlich kompatibel zu YAML 3.2.

Der Release-Zyklus war diesmal deutlich länger, zudem zwischen v3.1 und v3.2 keine sogenannten Maintenance-Releases eingeschoben wurden. Der Hauptgrund hierfür lag in der eng gestaffelten Veröffentlichung der aktuellen Browsergeneration, angefangen mit dem Internet Explorer 8 im Frühjahr 2009. Gerade bei diesem war es wichtig, die zuverlässige Funktion der Kernfunktionen des Frameworks ohne jegliche Hacks zu überprüfen. Nach nunmehr einem halben Jahr lässt sich dieser Fakt bestätigen. Einzig bei der Darstellung von Formularen benötigt der Internet Explorer 8 noch wenige individuelle Hilfestellung, die notwendigen Anpassungen kennt der Formularbaukasten jedoch.

Daneben stellt das 3.2-Release für mich eine weitere Schärfung des Profils von YAML hinsichtlich des modularen Aufbaus auf Basis eines sehr schlanken Kerns und der Focussierung auf flexible, barrierefreie Webseiten dar. Und die Entwicklung geht weiter ...

Der Framework-Core

Beinahe jedes CSS-Frameworks definiert sich durch so genannte Kernbausteine. Diese stellen die grundlegende Funktionalität bereit und sorgen für deren browserübergreifende Kompatibilität. Neben diesen Kernbausteinen bieten die einzelnen Projekte mal mehr, mal weniger optionale Bausteine an (Navigationsbausteine, Textformatierung, Formulare ect.), um den Entwicklungsprozess über die grobe Layouterstellung hinaus zu erleichtern. Genau in diesem Punkt klafft die Schere zwischen den einzelnen Projekten sehr weit auseinander. Diese optionalen Bausteine erhöhen zwangsläufig für den Einsteiger beim Erstkontakt die Komplexität, berühren aber eigentlich die Kernaufgabe der CSS-Frameworks (die Layouterstellung) nicht wirklich und erschweren die Vergleichbarkeit. Ich konzentriere mich deshalb beim folgenden Vergleich jeweils auf diese Kernbausteine, den so genannten Framework-Core folgender Projekte:

• YAML 3.2 (aktuelle Entwickerversion Beta 3)
• YAML 3.1
• YUI 3.0 beta1
• 960 grid system
• Blueprint CSS 0.9