CSS Media Queries

Die Sprache CSS („Cascading Style Sheets“, zu Deutsch „gestufte Gestaltungsbögen“) bildet mit HTML und JavaScript das Grundgerüst für die Entwicklung moderner Websites. Bei CSS handelt es sich um eine Programmiersprache, es werden jedoch keine einzelnen Schritte für die Lösung eines Problems beschrieben. Stattdessen wird ein Ziel definiert, das erreicht werden soll. Damit ist CSS ähnlich wie SQL eine deklarative Sprache.

Teil von CSS sind die sogenannten Media Queries, die die Eigenschaften eines Ausgabegeräts abfragen. Sie werden fürs Responsive Webdesign eingesetzt. Wie funktioniert dies genau?

Die CSS Media Queries wurden mit der CSS3-Spezifikation eingeführt. Ein Media Query bindet die Zuweisung von CSS-Eigenschaften eines Elements an eine oder mehrere Medium-Konditionen. Im einfachsten Fall wird unterschieden, auf welchem Medium Informationen dargestellt werden – auf einem Bildschirm, als gedruckte Seite (dies schließt auch die Ausgabe als PDF ein) oder als vorgelesener Text:

Ein CSS Media Query wird innerhalb eines CSS-Codeblocks über eine spezielle '@media'-Regel festgelegt. Die darin enthaltenen CSS-Selektoren und -Regeln werden nur unter der angegebenen Bedingung aktiviert. So lassen sich z. B. nicht darstellbare Elemente bei der Ausgabe als gedruckte Seite verbergen:

Neben dem zum Einsatz kommenden Medium lassen sich mit CSS Media Queries gezielt Eigenschaften des jeweiligen Mediums abfragen. CSS Media Queries sind damit das zentrale technische Feature, das Responsive Webdesign erst ermöglichte.

Responsive Webdesign zielt darauf ab, die Darstellung einer Webseite möglichst optimal an das jeweilige Gerät anzupassen. Media Queries werden genutzt, um verschiedene Eigenschaften des darstellenden Geräts, sogenannte Media Features, abzufragen. So ist es u. a. möglich, Style-Regeln für verschiedene Bildschirmdimensionen festzulegen. Ferner lassen sich optimierte Style-Regeln für den Fall definieren, dass ein mobiles Gerät gekippt wird.

Hier eine Übersicht der derzeit am häufigsten für Responsive Design genutzten Media Features:

Betrachten wir ein paar Beispiele. Stellen wir uns die Haupt-Überschrift einer Webseite vor. HTML sieht dafür das Element 'h1' vor. Zunächst werden wir für das h1-Element die Style-Regeln unabhängig vom darstellenden Gerät festlegen:

Als nächstes definieren wir einen Media Query, der die Breite des Bildschirms abfragt. Innerhalb der Abfrage legen wir die Style-Regeln fest, die ab dieser Breite für die Überschrift gelten sollen. Im spezifischen Beispiel erhöhen wir die Schriftgröße der h1-Überschrift auf Bildschirmen, die mindestens 1.024 Pixel breit sind:

Beachten Sie hier, dass wir nur die 'font-size'-Eigenschaft der h1-Überschrift anpassen. Der Zeilenabstand ist per 'line-height'-Eigenschaft als relative Einheit definiert und wird – da nicht explizit überschrieben – geerbt. Im konkreten Beispiel ist der Zeilenabstand des h1-Elements im Grundzustand 24px * 1,25 = 30px. Auf Bildschirmen ab 1.024 Pixel Breite ergibt sich proportional ein Zeilenabstand von 36px * 1,25 = 45px.

Diese Vermischung bestehender und neu definierter Style-Regeln wird im Namen CSS durch das Wort „Cascading“ ausgedrückt: ein Element erbt Style-Regeln von Eltern-Elementen oder generellen Regeln, die bereits definiert wurden. Für gewöhnlich legt man die Grundeigenschaften der Elemente fest und überschreibt dann selektiv Eigenschaften unter bestimmten Konditionen.

Ein weiteres Beispiel: Stellen Sie sich vor, wir möchten drei Elemente in einem Container darstellen. Dabei sollen die Elemente auf dem Bildschirm eines Mobilgeräts untereinander dargestellt werden, wenn das Gerät hochkant gehalten wird. Beim Kippen des Geräts auf Querformat soll das Layout umschalten, sodass die Elemente nebeneinander dargestellt werden. Mit dem Flexbox Layout Modul und einem CSS Media Query, der die Ausrichtung des Geräts abfragt, lässt sich das Layout in wenigen Zeilen HTML und CSS umsetzen. Zunächst definieren wir den Container und die enthaltenen Elemente in HTML:

Überdies definieren wir die folgenden CSS-Regeln. Wir setzen die Eigenschaft 'display: flex' auf dem Container und legen für diesen die 'flex-direction'-Eigenschaft per CSS Media Query konditional fest. Wird das Gerät im Querformat gehalten, werden die Elemente in einer Reihe nebeneinander angezeigt; bei Nutzung im Hochformat erfolgt die Anordnung der Elemente untereinander in einer Zeile:

Außer Bildschirmdimensionen und Ausrichtung des Geräts können wir auch die physische Auflösung des Bildschirms per Media Query abfragen. Dies ist insbesondere für die Darstellung von Pixel-Bildern interessant. Stellen Sie sich als Beispiel vor, dass ein Logo in zwei Versionen vorliegt, jeweils optimiert für Bildschirme mit niedriger und hoher Auflösung. Ein einfacher Trick dafür, das jeweils passende Logo anzuzeigen, besteht darin, beide Varianten auf der Seite zu platzieren. Mittels CSS Media Query fragen wir die Auflösung des Bildschirms ab und verbergen über 'display: none' die jeweils nicht benötigte Version. Dieser Ansatz könnte in HTML- und CSS-Code implementiert so aussehen:

In den bisherigen Erklärungen haben wir im Zusammenhang mit der verfügbaren Breite des Ausgabemediums vom „Bildschirm“ gesprochen. Dies ist konzeptuell zutreffend, technisch jedoch nicht ganz korrekt. Der Browser operiert intern mit dem Konzept des „Viewport“. Damit die Breite des Viewport tatsächlich mit der Breite des Bildschirms korrespondiert, wird eine 'meta-viewport'-Angabe im '<head>' des HTML-Dokuments benötigt. Ohne diese Angabe wird die Seite auf Mobilgeräten wie auf dem Desktop angezeigt, jedoch insgesamt stark verkleinert.

Beim Responsive Webdesign sollen sich die Elemente an die vorhandene Bildschirmfläche anpassen. Häufig geht es darum, die Dimensionen der Elemente unter verschiedenen Bedingungen festzulegen. Die CSS-Spezifikation definiert eine Vielzahl von Einheiten; die einfachste Dimensions-Einheit ist wohl das Pixel. Ein 1080p-Bild beispielsweise hat Dimensionen von 1.920 Pixel Breite mal 1.080 Pixel Höhe.

Das Pixel ist eine absolute Einheit und passt sich per Definition nicht an den vorhandenen Platz an. Schauen wir uns an einem Beispiel an, weshalb dies problematisch sein kann. Nehmen wir an, eine Webseite enthält ein Bild mit einer Breite von 1.920 Pixel. Legen wir die Bildbreite per CSS auf diesen Wert fest, kommt es ggf. auf kleinen Bildschirmen zu Störungen der Darstellung: Das Bild ragt über den verfügbaren Platz hinaus.

Hier definieren wir ein Bild in HTML mit dem '<img>'-Tag:

Per CSS fixieren wir die Breite auf 1.920 Pixel:

In diesem Szenario wäre es besser, statt Pixeln eine relative Einheit zu nutzen. Seit den frühen Tagen der tabellenbasierten Layouts kennt CSS das Prozent als relative Einheit. Setzen wir die Breite des Bildes per CSS auf '100%', passt das Bild sich fluide an den vorhandenen Platz an. Dies funktioniert, weil sich Prozentangaben immer auf das umschließende Element beziehen.

Wir sind unserem Ziel, die Breite eines Bilds an den zur Verfügung stehenden Platz anzupassen, ein gutes Stück näher gekommen. Jedoch haben wir ein neues Problem geschaffen: Auf einem Bildschirm, der breiter als 1.920 Pixel ist, wird das Bild vergrößert dargestellt und dadurch verpixelt. Daher sollten wir zusätzlich die maximale Breite des Bilds auf dessen tatsächliche Pixel-Dimensionen beschränken:

Neben Pixel und Prozent kennt CSS eine Reihe weiterer Einheiten. Die relativen Einheiten em, rem und vw, vh bieten allesamt interessante Einsatzmöglichkeiten im Responsive Design. Hier eine Übersicht der am häufigsten für responsives Design gebrauchten CSS-Einheiten nebst Verwendung:

Neben den bisher vorgestellten simplen Media Queries lassen sich auch komplexe CSS Media Queries schreiben. CSS sieht dafür die logischen Operatoren 'and', 'or', und 'not' vor. Hier ein Beispiel eines komplexen Query:

Zusätzlich zu den bereits etablierten Media Features, die sich per CSS Media Query abfragen lassen, wird es in Zukunft eine Reihe weiterer interessanter Features geben. So sieht die Spezifikation „CSS Media Queries Level 5“ (CSS5) u. a. die folgenden neuen Abfragemöglichkeiten vor:

Eine weitere Neuerung, die mit Erscheinen von CSS5 erwartet wird, sind die sogenannten Container Queries. Mit diesen wird es erstmals möglich sein, Style-Regeln für Elemente an die Eigenschaften des sie umgebenden Containers zu knüpfen. Damit stehen die Container Queries im Gegensatz zu den CSS Media Queries, die globale Eigenschaften des darstellenden Geräts abfragen. Der Einsatz von Container Queries wird die Behandlung von Spezialfällen erlauben, für die bisher auf JavaScript oder komplexe Media Queries zurückgegriffen wird.

Im Zusammenhang mit Responsive Webdesign und CSS Media Queries wird oft von „Breakpoints“ (zu Deutsch: „Umbruchstellen“) gesprochen. Bei einem Breakpoint handelt es sich um eine definierte Bildschirmbreite, bei der ein Satz von CSS-Regeln aktiviert wird, der per CSS Media Query definiert wurde. Sie können sich die auf einer Website definierten Breakpoints veranschaulichen, indem Sie im Browser die Developer-Tools öffnen. Ist die Responsive-Ansicht aktiv, werden die Breakpoints als farbige Balken oberhalb der eigentlichen Webseite dargestellt.

Eine anerkannte Best Practice des Responsive Webdesign ist der Mobile-First-Ansatz. Folgen Design und Entwicklung einer Website diesem Ansatz, werden die Style-Angaben für kleinste Bildschirme zuerst definiert. Diese Definitionen bilden das Grundgerüst des Designs. Darauf aufbauend werden mehrere Breakpoints für sukzessiv größere Bildschirme definiert. Innerhalb der Breakpoints werden selektiv neue Style-Regeln für Elemente festgelegt und damit die bestehenden Regeln für kleinere Bildschirme überschrieben.

Gut nachvollziehen lässt sich der Mobile-First-Ansatz am bekannten CSS-Utility-Framework „Tachyons“. Dieses definiert standardmäßig drei Breakpoints: 'not-small', 'medium' und 'large':

Beachten Sie, dass dem Mobile-First-Ansatz folgend kein eigener 'small'-Breakpoint existiert. Angaben für kleine Geräte werden einfach ohne Breakpoint definiert.

Innerhalb der Breakpoints werden Style-Regeln für Elemente festgelegt, deren Darstellung auf verschieden großen Bildschirmen angepasst werden soll. Vielleicht erkennen Sie bereits, dass diese Zentralisierung der CSS-Codebase eines Webprojekts problematisch ist. Normalerweise ist es vorzuziehen, sämtliche CSS-Eigenschaften eines Elements in einer eigenen Datei zu sammeln.

Um den CSS-Code eines Projekts zu modularisieren, kamen zunächst verschiedene CSS-Preprozessoren zum Einsatz. Vielleicht sind Ihnen die Sprachen Sass, Less oder Stylus ein Begriff. Später kam mit den Node.js-Projekt PostCSS ein CSS-Postprozessor hinzu. Alle genannten Technologien erlauben das Kapseln von CSS Media Queries unterhalb eines CSS-Selektors. So lassen sich die Style-Regeln eines Elements für sämtliche Media-Konditionen gesammelt definieren. Hier ein Beispiel mit Stylus.

Stylus-Datei 'text.styl' für Text-Eigenschaften:

Stylus-Datei 'link.styl' für Link-Eigenschaften:

Der Stylus-Preprozessor übersetzt die Dateien in CSS und sammelt die eingerückten CSS-Media-Query-Regeln unter einem einzigen Breakpoint. Der dargestellte Stylus-Code wird zum folgenden CSS-Code übersetzt:

Der Ansatz, CSS Media Queries innerhalb der Style-Regeln eines Elements zu kapseln und per CSS-Prozessor zu verarbeiten, funktioniert. Jedoch zwingt dies den Entwickler weiterhin dazu, zwischen den Ebenen HTML und CSS hin und her zu wechseln. Ferner besteht die Notwendigkeit, den Elementen in HTML eindeutige Klassennamen zuzuweisen. Die sich daraus ergebende Logistik führt zu unerwünschter Komplexität. Hier setzen die CSS-Utility-Frameworks an, eine heutzutage maßgebliche Technologie.

Ein CSS-Utility-Framework verknüpft atomare CSS-Eigenschaften mit Breakpoints. Die sich daraus ergebenden CSS-Klassen lassen sich in HTML einem beliebigen Element zuweisen. So wird es möglich, responsive Layouts und Komponenten nur in HTML zu definieren, ohne dafür CSS-Code schreiben zu müssen. Die Nutzung eines CSS-Utility-Frameworks erlaubt eine schnelle Prototypisierung und eignet sich hervorragend zur Entwicklung von Komponenten. Daher werden CSS-Utility-Frameworks oft in Verbindung mit komponentenorientierten Technologien wie React und Vue eingesetzt.

Betrachten wir ein weiteres, dem CSS-Utility-Framework Tachyons entlehntes Beispiel. Schauen Sie sich den folgenden CSS-Code an. Wir definieren zunächst die Klassen 'mw1' bis 'mw3', die die maximale Breite eines beliebigen Elements auf Werte zwischen '1rem' und '3rem' begrenzen. Ferner definieren wir innerhalb der bereits vorgestellten Breakpoints 'medium' und 'large' korrespondierende CSS-Klassen, die das Kürzel des jeweiligen Breakpoints im Namen tragen:

Mithilfe dieser CSS-Klassen können wir responsive Elemente komplett in HTML schreiben. Das folgende HTML-Codeschnipsel definiert ein Bild, das auf kleinen Bildschirmen eine maximale Breite von '1rem' hat. Das Bild passt sich automatisch an die verfügbare Bildschirmbreite an. Auf mittelgroßen Bildschirmen nimmt das Element maximal '2rem' ein, auf großen maximal '3rem'.

CSS-Utility-Frameworks definieren eine große Menge atomarer Klassen, wobei jede Klasse nur eine CSS-Eigenschaft festlegt. Dazu zählen neben den Dimensionen eines Elements Angaben zur Typografie, Farbgebung und so ziemlich allen weiteren denkbaren Eigenschaften. Für jede atomare Eigenschaft enthält ein CSS-Utility-Framework Klassen für jeden definierten Breakpoint. Durch die Kombination mehrerer Klassen lassen sich nahezu beliebige, vollständig responsive Elemente zusammenfügen.

Das bereits vorgestellte Framework Tachyons ist bereits einige Jahre alt und wird nicht aktiv weiterentwickelt. Aufgrund seiner relativen Einfachheit ist Tachyons jedoch zum Lernen von Responsive Webdesign weiterhin eine Betrachtung wert. Am einfachsten zu verstehen ist der Ansatz, wenn man sich die Tachyons-Komponenten anschaut. Dabei handelt es sich um Beispiel-Elemente, die vollständig über Utility-Klassen definiert sind.

Als geistiger Nachfolger von Tachyons existiert heutzutage mit TailwindCSS eine moderne Variante. TailwindCSS verfügt im Vergleich mit Tachyons über einige Vorteile. So wird das Projekt aktiv weiterentwickelt und unterstützt von Hause aus viele beliebte Systeme zur Frontend-Entwicklung. Ferner lässt sich TailwindCSS komplett an die jeweiligen Bedürfnisse eines Projekts anpassen. Sämtliche Voreinstellungen wie Breakpoints, Schriftgrößen-Skala etc. lassen sich einfach konfigurieren.

So praktisch die Arbeit mit CSS-Utility-Frameworks ist, sie haben auch einen großen Nachteil: Zur Definition eines Elements wird u. U. eine große Menge atomarer Klassen benötigt. Ferner enthält die CSS-Quelltextdatei standardmäßig Klassen für sämtliche Kombinationen von CSS-Eigenschaftswerten und Breakpoints. Im Falle von TailwindCSS handelt es sich um tausende von Klassen, was die CSS-Datei im unkomprimierten Zustand auf mehrere Megabyte Dateigröße anwachsen lässt – ein unter Performance-Gesichtspunkten nicht tragbarer Zustand.

Glücklicherweise schafft TailwindCSS auf zweierlei Weise Abhilfe. Zum einen kennt das Framework die '@apply'-Anweisung, die dazu dient, mehrfach genutzte Kombinationen von Utility-Klassen unter einem neuen Klassennamen zusammenzufassen. Zum anderen unterstützt TailwindCSS das Tool PurgeCSS. Dieses wird als Teil des Build-Prozesses eingesetzt, um alle nicht genutzten Utility-Klassen aus dem Produktions-Build zu entfernen. PurgeCSS prozessiert dazu die HTML-Templates des Projekts und nimmt nur die dabei gefundenen CSS-Klassen in die erzeugte CSS-Quelltextdatei auf. Dadurch sinkt die Größe der Quelltextdatei auf ein akzeptables Maß.