Unter responsivem Webdesign versteht man, dass das Layout einer Webseite für das Ausgabemedium angepasst wird. Übersetzt wird das englische Adjektiv „responsive“ etwa mit „ansprechbar“, „empfänglich“, „zugänglich“ oder „antwortend“, was auf den ersten Blick nicht sehr viel mit dem Internet zu tun hat.
Brad Frost zeigt in Responsive Web Design: Missing the Point[1], dass es nicht darum geht, neben einer Desktop-Version noch eine oder mehrere mobile Layoutvarianten zu erstellen, sondern Seiten zu erstellen, die möglichst geräteunabhängig schnell laden und überall gut aussehen.
Webdesign bedeutet
Webdesign schafft eine flexible Konstruktion, eine dehnbare Architektur, die sich in unterschiedliche Räume einfügt, technische Besonderheiten berücksichtigt und Spielraum lässt für individuelle Gegebenheiten. Webdesign ist immer Gast auf fremden Bildschirmen.
Da die meisten Webseiten schon in irgendeiner Form vorhanden sind, liegt es nahe, dieses Layout an bestimmten Breakpoints mittels Media Queries an kleinere Viewports anzupassen. Dabei stand man vor dem Problem, dass Dekorationen und Grafiken nicht auf die kleineren Monitore passen. Trotz der Bandbreitenbegrenzungen vieler Mobilfunk-Verträge wurden diese aber mitübertragen und geladen, dann aber ausgeblendet.
Luke Wroblewski hatte in seinem Buch „Mobile First!“ die Idee, den Prozess umzudrehen und mit einer abgespeckten, mobilen Version zu beginnen. Dies sollte aber kein Selbstzweck sein, sondern den Fokus wieder auf die ältere, aber immer noch gültige Maxime „Inhalt über Design“ und andere Usability-Grundsätze legen.
Mobile First baut auf folgenden Tatsachen auf:
Es ist also zweckmäßig, als erstes die allgemein gültigen Definitionen und die für kleine Bildschirme ins CSS zu schreiben und dann erst in einer Media Query das CSS für große Bildschirme. Ansonsten bräuchte man entweder zwei komplett unterschiedliche Stylesheets oder würde erst alles für große Bildschirme in Spalten anordnen und dies dann für Geräte mit kleinem Bildschirm alles wieder rückgängig machen.
Mobile First sollte folglich nicht bedeuten, dass mobile Endgeräte bevorzugt werden, sondern, dass das Layout für mobile Geräte aus praktischen Gründen vor den Anpassungen für den Desktop in der CSS-Datei liegt.
Agnostizismus (altgriechisch ἀγνοεῖν a-gnoein „Unwissen“) ist die philosophische Ansicht, dass Annahmen – insbesondere theologische, die die Existenz oder Nichtexistenz einer höheren Instanz, beispielsweise eines Gottes, betreffen – entweder ungeklärt oder grundsätzlich nicht klärbar sind.
Trent Walton bevorzugt anstelle des Begriffs Responsive Webdesign den des Device-Agnostic. Damit will er betonen, dass Webdesigner nicht ahnen können, welche Geräte mit welchen Fähigkeiten Benutzer einsetzen werden und daher möglichst geräteunabhängig gearbeitet werden soll. Dabei geht seiner Meinung nach die Betonung weg von der Responsiviät mittels Media queries und hin zu Techniken, die geringe Übertragungsraten in mobilen Netzen und Besonderheiten der Toucheingabe genauso berücksichtigen.
Viele JavaScript-Interaktionen und CSS-Hovereffekte funktionieren auf Touchgeräten nicht, da es kein mouseover und kein :hover gibt. Zum Teil versuchen die Browser dieses Verhalten nachzuahmen, besser ist es jedoch bereits bei der Programmierung Touch-Events zu implementieren.
Webseiten im Fullscreen-Modus können mit ESC wieder in die klassische Ansicht zurückgesetzt werden, nur nicht auf Touch-Geräten, da es dort keine Tasten gibt. Auch der Klammergriff ( strg + alt + entf ) ist auf Touchgeräten nicht möglich.
Scott Jehl legte in seinem Artikel „Planning for Performance“ das Augenmerk auf die sich immer weiter steigernde Datenmengen, die heutige Webseiten ausliefern. Während die durchschnittliche Webseite 1,7 MB groß ist, haben manche responsive Seiten wie disney.com, die für jeden Browser die passenden Frameworks, Grafiken und Skripte ausliefern, über 5 MB, teilweise sogar über 100 MB!
Gerade angesichts der Tatsache, dass Benutzer mobiler Geräte nicht nur über WLAN, sondern auch über 3G surfen, sollten Webseiten nicht nur responsiv, sondern auch schlank sein. Das Surfen im Mobilnetz bewirkt eine zeitliche Verzögerung von 2 Sekunden beim Seitenaufbau, da der Datenstrom vom Server zusätzlich noch den Funksender des Mobilfunknetzes passieren muss.
Auch wenn LTE und 4G diese Antwortzeiten verringert haben, ist mobiles Surfen an sich langsamer als Surfen mit WLAN oder in Kabelnetzen. Deshalb sollten Sie versuchen, die Anzahl der http-Requests so gering wie möglich zu halten. Normalerweise blocken externe CSS-Dateien und JS-Skripte im Unterschied zu Grafiken das Rendering einer Seite. Durch das Nachladen von Stylesheets mit Hilfe von Skripten und nachträglichem Einfügen mittels document.write wird der schon gerenderte Seiteninhalt wieder verändert.
Empfehlung: Vermeiden Sie ein Laden der Seite, bevor die Stylesheets geladen sind. Dieses FOUC (Flash of unstyled Content) ist extrem ärgerlich und verzögert den Seitenaufbau.
Das Grundgerüst sollte auf jeden Fall die Sprache, den Zeichensatz und auch den Viewport beinhalten:
<!--responsives HTML-Grundgerüst--> <!doctype html> <html lang="de"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Titel</title> </head> <body> </body> </html>
Dabei ist besonders die letzte Meta-Angabe wichtig, damit sich Webseiten einerseits an die verfügbare Breite anpassen, aber auch skalieren lassen.
Wenn Sie alle Seiten in Ihrem Code-Editor wie z. B. Notepad++ öffnen, können Sie die ersten fünf Zeilen durch „Suchen und Ersetzen“ in allen Dateien einfügen. Eine Angabe von utf-8 ist aber nur sinnvoll, wenn die Seiten dann auch in diesem Format gespeichert werden.
Häufig reichen einige wichtige Änderungen am CSS, um eine Webseite zumindest großteils responsiv zu gestalten. Webseiten aus den 90ern mit einem Liquid Layout passten sich auch damals schon an verfügbare Breiten an, ließen in Tabellen und mehrspaltigen Layouts längere Wörter aber über den sichtbaren Rand überstehen.
Das Haupthindernis herkömmlicher Seiten ist der Versuch eines pixelgenauen Designs. Durch unterschiedliche Darstellungen auf verschiedenen Plattformen, sowie durch Retina-Displays ist dieser Ansatz von vornherein zum Scheitern verurteilt.
Diese Website ist optimiert für eine Auflösung von 800×600 und den Internet Explorer 6.
Kennen Sie diesen Hinweis aus der Anfangszeit des Webs noch? Machen Sie nicht den Fehler und versuchen Sie nun neben Ihrer Desktop-Version eine oder mehrere Versionen für bestimmte Viewport-Größen zu erstellen. Brad Frost zeigt, dass es mittlerweile unmöglich ist vorherzusagen, mit welchen Endgeräten Nutzer heute oder gar morgen Ihre Webseite besuchen werden.
Unser Ausgangsbeispiel ist eine aside-Box innerhalb einer kleinen Webseite, wie sie auch im HTML-Einstieg vorgestellt wird:
#kontakt {
border: solid 1px red;
float: right;
margin-right: 10px;
height: 125px;
width: 145px;
}
<aside id="kontakt">
<h2>Kontakt</h2>
<p>Telefon: 01234 4711</p>
<p>7 - 17 Uhr, sonst AB</p>
</aside>
Die aside-Box ist pixelgenau abgemessen, sodass Überschrift und zwei Zeilen Text exakt hineinpassen. (Im Normalfall hätte man den Absätzen noch etwas padding gegeben.) Sie wird mit float:right; rechts positioniert (Eine bessere Alternative zeigen wir Ihnen im nächsten Abschnitt.)
Bei einer Änderung der Schriftgröße durch den Entwickler müssten die Breite und Höhe angepasst werden. Bei der Änderung der Schriftgröße durch den Nutzer im Browser oder durch ein User-Stylesheet würden die Textzeilen umbrechen und aus dem Rahmen - bei overflow:hidden; sogar aus dem sichtbaren Bereich wandern.
Was soll ich denn dann anstelle von Pixel nehmen?
Ein guter Ausgangspunkt für responsive Webseiten ist die aktuelle Schriftgröße als Basisgröße. 1em repräsentiert die vom Browser berechnete Schriftgröße des Elements; es geht dabei kaskadierend von der Schriftgröße des Elternelements aus. Sofern vom Benutzer nicht anders eingestellt, beträgt die eingestellte Schriftgröße in den meisten Browsern 16px, der genaue Wert ist aber egal, da wir ja flexibel und responsiv werden wollen.
In vielen älteren Webseiten wurde die Schriftgröße bewusst auf einen kleinen Wert festgelegt, damit mehr Text ins Layout passt. Auf mobilen Geräten ist dies jedoch viel zu klein.
html { font-size: 9px; }
Verzichten Sie im Normalfall auf die Festlegung einer festen Schriftgröße. Verwenden Sie statt dessen em (bezieht sich auf die Schriftgröße des Elternelements) oder, falls sich die Größe auf das Root-Element beziehen soll, rem.
Diese Schriftgröße kann (und sollte) auch als Basis für Breitenangaben von Elementen verwendet werden:
#kontakt { border: solid thin red; float: right; margin-right: 1em; width: 9em; }
Die Breite ist in der relativen Maßeinheit em angegeben. Bei einer Änderung der Schriftgröße wächst die Breite der aside-Box einfach mit.
Eine Angabe einer Höhe ist im Allgemeinen nicht notwendig. Bei der Verwendung von flexiblen und prozentualen Breiten ist es sogar kontraproduktiv: Wenn der Inhalt auf schmalen Viewports zusammengeschoben wird, muss er nach unten ausweichen können und nicht über den Rand herausragen oder gar verschluckt werden.
Um bei vielen verschachtelten Elementen mit verschiedenen Festlegungen nicht durcheinanderzukommen, können Sie auch die Einheit rem (root em = Wurzel-em) verwenden, die sich auf die Schriftgröße des root-Elements html bezieht.
Um mit wenigen Handgriffen schon sichtbare Ergebnisse zu erzielen, durchforsten Sie ihr Stylesheet:
Verwende:
Verzichte:
CSS bietet mehrere Möglichkeiten durch eine browserinterne Eigenschaftsabfrage unterschiedliche Darstellungen zu erreichen.
Die heutzutage üblichste Variante ist der Einsatz von media queries (engl. für Medienabfragen), mit denen dann unterschiedliche Festlegungen für unterschiedliche Breiten, aber auch für andere Kriterien, getroffen werden können.
/* Kompaktes Layout für mobile Geräte */ #kontakt { border: solid thin red; float: right; margin-right: 1em; } @media (min-width: 30em) { /* mehrspaltiges Layout für breitere Bildschirme */ #kontakt { float: right; width: 9em; } }
Die aside-Box nimmt auf kleinen Bildschirmen die volle Breite des Viewports ein. Folgende Inhalte werden darunter dargestellt. Als Breakpoint wird eine Breite von 30em genommen.
Wo soll ich denn meine Breakpoints setzen? Welche Maße haben die meistverwendeten Smartphones?
Erkennen Sie den schon oben angesprochenen Denkfehler?
Es ist heutzutage unmöglich, genaue Werte für Geräte-Abmessungen zu ermitteln, da eine Vielzahl dieser Geräte am Markt ist. SmartPhones werben mit 2000 (Geräte)Pixeln, Phablets lassen die Grenzen zwischen Phones und Tablets immer weiter verschwimmen. Hochauflösende 4K-Monitore sollen nicht für die mögliche Anzeige von mehreren DIN A4 Seiten in Mini-Schrift verwendet werden.
Die Breakpoints sollen sich nicht auf einige Endgeräte, sondern am Inhalt ausrichten.
Mit Grid-Layout (siehe 7.4.8) können Sie Elemente beliebig in einem responsiven Raster anordnen.
Das Geniale dabei ist der mögliche Verzicht auf jegliche Breitenangaben:
body {
display: grid;
gap: 0.5em;
}
@media (min-width: 30em) {
/* Breite beträgt mindestens 30em */
body {
grid-template-columns: 1fr 3fr;
grid-template-rows: auto 1fr 100px;
}
}
Unsere Beispielseite enthält im Body ein Grid (=Raster), das aber noch nicht weiter definiert ist. Erst ab einer Breite von 30em entstehen mit grid-template-columns nun zwei Spalten, die sich im Verhältnis 1 zu 3 aufteilen (fr steht für fraction, engl. für Bruchteil.
Ein Aspekt wird bei responsiven Webdesign oft vergessen: Neben vielen kleinen Viewports auf mobilen Geräten werden die Monitore auf dem Schreibtisch immer größer.
Textzeilen, die sich über 2550 oder sogar 4000 Pixel Breite erstrecken, sind nur noch schwer lesbar. Als Empfehlung hat sich eine Reduzierung der maximalen Seitenbreite auf ca. 60em durchgesetzt:
body { max-width: 60em; margin: 1em auto; }