Unabhängig von einem möglicherweise verwendeten Framework sind alle fluiden Grids gleich aufgebaut: Es gibt eine festgelegte Anzahl Spalten, welche durch Abstände, sogenannte Gutter, horizontal getrennt werden. Bei fluiden Grids werden sowohl die Breiten der Spalten als auch die der Gutter in Prozent angegeben.

Aber machen diese Eigenschaften eines fluiden (oder auch fixen) Grids in einer responsiven Umgebung überhaupt noch Sinn? 12 oder 16 Spalten auf kleinen Smartphones? Proportional zur Breite anwachsende Gutter, die zu einer Art „Zieharmonika-Effekt“ führen? Ausnutzung des zur Verfügung stehenden Platzes auf größeren Bildschirmen durch breitere statt durch mehr Spalten?

Eine mögliche Lösung

Das Golden Grid System von Joni Korpi zeigt einen möglichen Lösungsansatz: Ein „Falt-Grid“, dessen Spaltenanzahl sich an der zur Verfügung stehenden Breite des Bildschirms orientiert. Die 16 Spalten der großen Desktop-Bildschirme werden für Tablets auf 8 und für Smartphones auf 4 Spalten „zusammengeklappt“. Als „Abfallprodukt“ kommt das Golden Grid ohne „seltsame“ Spaltenbreiten wie z.B. 8.33333333 Prozent aus

Zudem wird das Gutter nicht über Außenabstände (margin), sondern Innenabstände (padding) der Grid-Boxen erzeugt – was die Schwäche dieses Ansatzes ist. Die dafür notwendige CSS-Eigenschaft box-sizing, welche das box model des betreffenden Elementes ändert, wird nur von neuesten Browsern unterstützt, speziell ältere Versionen des Internet Explorers scheitern also an dieser Technik.

Anders, komplizierter und einfacher

Nehmen wir nun an, man würde das Gutter nicht über die Innenabstände der Grid-Boxen, sondern die Außenabstände von deren Kindelementen erzeugen – also kein padding per box-sizing für einen Container, sondern horizontaler margin für die in diesem enthaltenen Elemente. Das funktioniert in allen Browsern problemlos und ist kein optischer, sondern lediglich ein technischer Unterschied.

Will man diese Abstände allerdings – wie das padding im Golden Grid – in em angeben, artet das ziemlich in (Rechen-)Arbeit aus. Solche Berechnungen lassen sich mit CSS-Präprozessoren wie LESS oder SASS recht bequem automatisieren, im gleichen „Rutsch“ kann man den Präprozessor auch über Mixins das Erzeugen der Grids für die verschiedenen Auflösungen erledigen lassen.

Unfug oder sinnvolle Anpassung fluider Grids an Responsive Webdesign?

Was bisher geschah …

Wie ich bereits beschrieb, halte ich Grid-Frameworks für eher wenig tauglich für Responsive Webdesign, letzteres aber für eine unbedingt zu verinnerlichende und in den alltäglichen Workflow zu integrierende Technik. Damit fällt nicht nur 960.gs (welches ohnehin mit fixen Breiten arbeitet) weg, sondern auch etliche andere Frameworks, z.T. selbst die Vertreter, welche ein fluides Grid bereit stellen – sie machen individuelle Anpassungen erforderlich, vertragen sich wenig mit „mobile first“, weil sie es nicht bedenken, und sind normalerweise spätestens dann unbrauchbar, wenn man eine grafische Vorlage zur Umsetzung angeliefert bekommt. Dann kann man sich genausogut gleich ein fluides Grid selbst bauen, der Unterschied im Aufwand ist eher gering.

Neue Frameworks

Nun ist es durchaus nicht so, dass sich seit 960.gs und Co. nichts getan hätte. Es gibt neue Ansätze und Ideen für fluide und responsive Grid-Layouts, die durchaus vielversprechend aussehen:

• Das Semantic Grid System setzt basierend auf dem CSS-Präprozessor LESS fixe, fluide und responsive Layouts mit verblüffend wenig selbst zu schreibendem Code um. Mein Problem damit ist die zusätzliche Schicht in Form von LESS – es würde den Rahmen sprengen, es hier detailliert zu erklären, aber ich habe noch keinen CSS-Präprozessor gefunden, der sich ohne Widerhaken in meine individuelle Arbeitsweise integriert.
• Das Golden Grid System hat aus meiner Sicht ähnliche „Probleme“ wie sein Vorgänger Less Framework – die grundsätzlichen Ideen dahinter sind gut und richtig, aber (z.T. durch Einschränkungen durch die fehlende CSS3-Unterstützung) praktisch nicht effizient umzusetzen. Benutzt man es konsequent, hat man damit zudem relativ viel Arbeit, weil es kaum Klassen vordefiniert (was vom Ansatz her grundsätzlich gut, aber eben aufwändig ist).

Gibt's da nichts vom W3C?

Noch nicht. CSS3 enthält ein paar vielversprechende Module, welche das Layout-Problem im Web beheben sollen – letztlich kann man selbst die Layouts, die wir jetzt benutzen (müssen), als Zweckentfremdung der float-Eigenschaft betrachten. Die Module Template Layout, Grid Positioning und Flexible Box Layout werden uns großartige Möglichkeiten geben und Grid-Frameworks vermutlich überflüssig machen, wenn sie denn erstmal mehr als nur ein Entwurf sind.

Bis dahin allerdings halte ich es für die sauberste und beste Lösung, Grid-Layouts individuell von Hand zu bauen, auch wenn das mehr Arbeitsaufwand bedeutet.

Jeder kennt das Spiel Schere, Stein, Papier. Übertragen auf Responsive Webdesign müsste es eine Regel namens „Layout übertrumpft Auflösung“ geben. Denn es geht weder darum, eine Seite „für das iPad“ noch „für 768 Pixel Breite“ zu optimieren – das sind Relikte aus den Anfangstagen unserer jungen Zunft, in denen wir (viel zu) viel aus der artverwandten Print-Ecke übernommen haben.

Frage nicht, was das Display hergibt …

Ich glaube, dass jedes responsive Layout individuell umgesetzt werden sollte. Der entscheidende Aspekt dieser Technik sind die „breaking points“, also die Breiten, ab denen ein von Natur aus flexibles Basis-Layout nicht mehr vernünftig lesbar ist und mit Media queries korrigiert bzw. umgestellt werden muss.

Diese Punkte sollten aber nicht durch bestimmte Geräte und ihre Auflösungen definiert werden, sondern durch Layout und Design sowie die Frage, in welcher Auflösung sie funktionieren. Nebenbei macht dieser Ansatz ein bestimmtes Design auch zukunftssicherer in Bezug auf neu erscheinende Geräte.

… frage, wonach das Layout verlangt

Konkret prüft man also (unabhängig vom Gerät), innerhalb welcher Bereiche der Breite ein bestimmtes Layout „funktioniert“ und passt es außerhalb dieser Bereiche an. Das ist der entscheidende Unterschied dieser Technik zur vertrauten Vorgehensweise. Das wird noch klarer, wenn man sich des Ansatzes „mobile first“ bedient. Dann lautet die Frage auch nicht mehr, ab welcher Viewport-Breite ein Layout nicht mehr funktioniert – dann geht es darum, ab welcher Breite bestimmte Aspekte des Layouts und Designs erst möglich oder sinnvoll sind.

Eine Einschränkung in puncto Geräte gibt es, aber auch die sollte unabhängig von der Auflösung gesehen werden. Die meisten kleinen Displays sind heutzutage Touchscreens, für die man das Design durchaus anpassen sollte – in Form größerer Buttons und anders gestalteter Navigationselemente etwa.

Responsive Web Design ist also idealerweise quasi Progressive Enhancement für Layouts, ähnlich dem Ansatz, den Modernizr nutzt: Entscheidend ist nicht, welcher Browser eine Seite anfordert; entscheidend ist, was in diesem Browser möglich ist. Der gemeinsame Vorteil dieser Ansätze ist, dass sie uns unabhängig von Dingen machen, die wir ohnehin nicht hinreichend zuverlässig vorhersagen können – beispielsweise die Bildschirmauflösungen, mit denen unsere Webseiten betrachtet werden.

Media-Query-Krücken

Bekanntlich unterstützen verschiedene ältere Generationen gängiger Browser die Kernkomponente @media in Kombination mit Dimensionsangaben nicht. Das gilt nicht nur für den allseits beliebten Wunderbrowser aus Redmond, aber dort fällt es ins Gewicht – der gemeine Nutzer von Firefox, Chrome & Co. ist ja eher updatefreudig (und in der Lage dazu).

css3mediaqueries.js schien mir bislang die ausgereifteste Lösung, doch nun holt respond.js merklich auf. Es ist schmaler und nicht ohne Tücken, wird aber aktiv entwickelt. In neuester Version kommt es ohne den Kommentar hinter der schließenden Klammer eines @media aus, womit es kein Problem mehr ist, das zugehörige Stylesheet zu minifizieren. Vor allem aber: respond.js ist neuerdings Teil von Modernizr, womit man sich einen HTTP-Request sparen kann, wenn man Modernizr ohnehin nutzt.

Kleiner Bildschirm vs Navigation

Ein echter Stolperstein ist es nicht, eher eine „kreative Einschränkung“ – Aufbau und Gestaltung von Navigationen in Layouts für ganz kleine Bildschirme wie etwa die 320×480 Pixel eines Smartphones. Klassische Navigationsdesigns, wie man sie von altbekannten Auflösungen her kennt, funktionieren da nur selten, ganz haarig wird es natürlich, wenn eine zweite Ebene oder gar eine Dropdown-Navigation verwendet wird.

Die Alternative für kleine Bildschirme soll kompakt sein, gleichzeitig aber möglichst große Flächen und/oder Schriften haben, damit man sie selbst mit den übelsten Wurstfingern auf einem Touchscreen noch bedienen kann. Da hat man rasend schnell den (ersten) Bildschirm nur mit 5 bis 6 Menüpunkten gefüllt, aber es sollte ja zumindest auch noch eine Andeutung von Inhalt erscheinen …

Der bisher pfiffigste Lösungsansatz, den ich bislang dazu gesehen habe, ist es, die Navigation am Ende des Quelltextes auszugeben und am Seitenanfang lediglich einen Skiplink zur Navigation zu verbauen – quasi das etwas andere „content first“. Auf größeren Auflösungen holt man die Navigation dann mit position: absolute; nach oben und verbirgt den Skiplink mit geeigneten CSS-Mitteln.

Das Buch

Last, but not least liegt mit Responsive Web Design aus der allgemein ganz hervorragend gemachten und sehr lohnenswerten A Book Apart-Schmiede nun das gedruckte Standardwerk zum Thema vor. Dazu mehr, sobald ich mein (gedrucktes) Exemplar in den Händen halte.

Was ist neu in Version 2?

• Media query-Tests: Testen, ob der Browser Media queries unterstützt, bestimmte Ressourcen (CSS/JS) abhängig von bestimmten Bildschirmdimensionen laden
• Ressourcen nachladen: Über den (im Modernizr integrierten!) Loader yepnope können CSS- oder JS-Dateien abhängig von bestimmten Testergebnissen nachgeladen werden
• Präfix-Tests: Es gibt neue Tests für die sogenannten vendor prefixes, also proprietäre CSS-Erweiterungen einzelner Browser

Darüber hinaus kann man Modernizr in der neuen Version um eigene Tests erweitern sowie sich über das Build-Tool eine angepasste Version abholen, welche nur die tatsächlich benötigten Tests enthält.

Ein einfaches Beispiel

Modernizr.load([
    {
        test: Modernizr.fontface && !Modernizr.touch,
        yep: 'font/myfont.css'
    }, {
  	    load: '//ajax.googleapis.com/ajax/libs/jquery/1.6.1/jquery.min.js',
  	    complete: function () {
  	    	if (!window.jQuery) {
  	    		Modernizr.load('js/libs/jquery-1.6.1.min.js');
  	    	}
  	    }
    }, {
        test: Modernizr.mq('only all and (max-width:480px)'),
        yep: 'css/smartphone.css'
    }
]);

Dieses Beispiel (den Code hängt man an die modernizr.js an) lädt:

1. ein Stylesheet, wie es zu den Webfont-Kits von FontSquirrel gehört – aber nur in Browsern, die Webfonts unterstützen und nicht auf Touchscreen-Geräten
2. jQuery vom Google-CDN oder, falls das scheitert, eine lokale Kopie als Fallback
3. ein Stylesheet für Smartphones nur in Browsern, deren Viewport mindestens 480 Pixel breit ist

Das demonstriert natürlich nur einen Bruchteil der Fähigkeiten von Modernizr, um den Rahmen dieses Artikels nicht zu sprengen. Man kann also mit Version 2 dank yepnope-Integration nun Polyfills, aber auch CSS/JS für bestimmte Umgebungen dynamisch nachladen. Genial einfach, einfach genial.

Äh, und ohne Javascript?

Bei deaktiviertem Javascript JS-Dateien nachzuladen ist ohnehin komplett sinnfrei – das Zauberwort heißt hier unobtrusive JS, also die gängige Praxis, Seiten so zu bauen, dass sie auch ohne JS zugänglich und benutzbar sind. Genauso sollte man natürlich auch nur CSS-Dateien per Modernizr.load nachladen, die verzichtbar sind bzw. die nur innerhalb der Test-Bedingung notwendig sind.