Die Theorie der responsiven Webseiten
Seite 2: Layout
Die wohl am häufigsten verwendete Regel ist die der min- und max-width/height-Angaben. Letztere bestimmen, ab welcher Breite oder Höhe von Browser und Gerät eine CSS-Klasse anzuwenden ist. Es gibt eine Hand voll relativ häufig verwendeter Größen (Breakpoints), die im Internet kursieren. Sie reichen von 320 Pixel für ein Smartphone im Hochformat über 768 Pixel für Tablets und 1024 beziehungsweise 1200 Pixel für Desktops. Natürlich lassen sich noch weitere finden, aber sie stellen in gewisser Hinsicht Richtlinien dar, an die sich viele Webentwickler halten. Es ist ungewiss, wie genau sich die Geräte in Zukunft ändern, aber eines ist sicher: Sie werden, dem 5-Inch-Trend der aktuellen Smartphones folgend, größer und werden vor allem mit einer höheren Pixeldichte ausgestattet sein. Das soll heißen, dass immer mehr Details auf kleinstem Raum Platz finden müssen.
Daraus folgt, dass nicht nur für kleine Geräte zu optimieren ist, sondern auch beispielsweise Bilder für hochauflösende Bildschirme zur Verfügung zu stellen sind. Auch auf Bildschirmen jenseits von FullHD (1920x1080 Pixel) kann eine Webseite schnell einer Miniaturausgabe gleichen.
Relative Größen nutzen
Schritt eins für responsive Webseiten lautet: Abschied von festen Größenangaben nehmen. Pixelangaben sind statisch und helfen bei RWD nicht viel. Jeder Webentwickler hat irgendwann einmal von em gehört, auch wenn diese Angabe oft missverstanden wird. Dabei ist die Formel für die Berechnung ganz einfach:
Ziel / Kontext = Ergebnis
Unter der Annahme, dass der Body einer HTML-Seite eine Schriftgröße von 12 Pixeln hat, sollte das primäre Header-, sprich das H1-Element, 18 Pixel groß sein. Mit den Angaben lässt sich die Formel wie folgt nutzen:
18 (Ziel: H1) / 12 (Kontext: Body) = 1.5em
h1: {
font-size: 1.5em;
}
Berechnet man die Schriftgröße immer anhand des Eltern-Elements, kann das bei komplexen Webseiten zu unerwünschten Nebeneffekten führen. In CSS3 wurde daher eine etwas veränderte Version eingeführt:rem (Root em). Im Gegensatz zu den bekannten em verhalten sie sich nicht relativ zum Eltern-Element, sondern zum Viewport der Seite. Davon profitieren vor allem tief verschachtelte Elemente. Mittlerweile gibt es eine breite Unterstützung von Seiten der Browser und alternative Lösungen. Vor allem, wenn CSS-Präprozessoren wie LESS zum Einsatz kommen, lässt sich auf der Serverseite die Größe berechnen und in Pixeln kompilieren.
Für Layouts gibt es mittlerweile ähnliche Ansätze, zum Beispiel die Angaben viewport-percentage-length. Sie verhalten sich, wie der Name schon sagt, relativ zum Viewport der Seite. Das heißt, dass 1 vw bei einer Viewport-Breite von 480px gleich 4,8 Pixeln ist. Dasselbe gilt für die Höhe mit vh, während sich vmin und vmax dazu verwenden lassen, um die größere oder kleinere Angabe der Breite oder Höhe zu finden. Vor allem bei Containern, die 100 Prozent der Höhe haben sollen, sind solche Angaben willkommen: Im Moment kann man so einen Fall nur unter Berücksichtigung aller Parent-Elemente ermitteln, was letztlich fast immer einen JavaScript-Hack nötig macht.
Arbeitserleichterung und Aufbau
Vor allem zu Projektbeginn sollten Entwickler überlegen, ob für Aufgaben wie die Unterteilung in ein Box-Modell (um beispielsweise Elemente auf kleinen Geräten untereinander darzustellen), ein Framework geeignet ist. Mittlerweile ist die Auswahl groß und reicht von kleinen Frameworks, die sich auf die Funktion beschränken, CSS-Klassen für ein Grid-Layout bereitzustellen, bis hin zu kompletten Baukästen wie Twitter-Bootstrap. Vorteile der Frameworks liegen unter anderem in der verbesserten Browserkompatibilität, den Lösungen zu allgemeinen CSS-Problemen und der Hilfe, die sie durch standarisierte Klassen bei der Entwicklung im Team bieten.
Da gerade bei responsiven Webseiten die Performance eine große Rolle spielt, kann es auf lange Sicht kontraproduktiv sein, unüberlegt ein "All-inclusive"-Framework einzusetzen. Komplette Frameworks locken mit vielen nützlichen und zeitsparenden Features und erleichtern das Erstellen von Prototypen erheblich. Genau dafür sind sie besonders zu empfehlen. In allen anderen Fällen versucht man jedoch in der Regel, jedes überflüssige Kilobyte einzusparen, sodass Frameworks schnell die erste Adresse zum Reduzieren der Datenmenge sind. Vor dem Einbau sollte daher jeder Entwickler gut überlegen, welche Features er letztlich verwenden möchte, um die Charakteristiken der einzelnen optimal ausnutzen zu können und keine unnötige Last zu erzeugen.
Die oben angesprochenen Grid-Systeme unterteilen das Layout in mehrere Zeilen und Spalten. Das im Twitter-Bootstrap integrierte Grid etwa stellt zwölf Spalten dar, wie es in vielen weiteren Frameworks der Fall ist. Sie lassen sich mit CSS-Klassen (col-md-1 bis col-md-12, md steht für Medium Device) auf Elemente anwenden und wie folgt definieren:
<div class="row">
<div class="col-md-6">6 Spalten</div>
<div class="col-md-6">6 Spalten</div>
</div>
<div class="row">
<div class="col-md-2">2 Spalten</div>
<div class="col-md-10">10 Spalten</div>
</div>
Das Umsetzen des Verhaltens der Spalten auf unterschiedlichen Geräten ist nun Aufgabe des Frameworks. So sorgt es etwa dafür, dass Spalten, die auf einem Desktop nebeneinander angezeigt werden, sich auf kleinen Devices untereinander schieben. Über das Hinzufügen von CSS-Klassen lässt sich das noch etwas feiner steuern: Mit dem Klassen-Präfix .col-xs (xs steht für Extra Small Devices mit Auflösungen unter 768px) kann man etwa erreichen, dass die Klassen nur für die angegebenen Auflösungen zum Einsatz kommen.
