DH
David Hellmann
2014/05/19

CSS Media Queries: Das Problem mit fixen Breakpoints

CSS Media Queries sind allgegenwärtig und nicht mehr wegzudenken heute. Ermöglichen sie es uns doch, dass wir eine Website gezielt steuern können. Wir reden hier meistens von Breakpoints, die man einfach braucht, um gewissen Problemen in der Darstellung entgegenzuwirken. Das soll kein Einblick in Media Queries werden, denn dazu kann man sich woanders besser Informieren: W3C — Media Queries. Es geht mir mehr um den Umgang damit bzw. den falschen Umgang.

Desktop first, jeden Falls im Moment…

Ich arbeite aktuell immer von oben nach unten was die Gerätegrößen angeht. Nicht nur in der Entwicklung sondern auch beim Design. Es gibt ja auch den Mobile First Ansatz aber damit konnte ich mich bisher nicht anfreunden. Aber aus meiner Sicht ist es eh falsch zu sagen, dass Ansatz A oder B richtig ist. Vielmehr sollte es so sein, dass man den zum Projekt richtigen Ansatz definiert und dann auch konsequent nutzt. Mobile First ist aber nichts für die Entwicklung oder das Design, sondern ein ganzheitlicher Ansatz, den man von Projektbeginn an leben muss. Aber darum soll es hier gar nicht gehen.

In den Beispielen hier wird zu 95% immer (max-width: xxxpx) auftauchen. Aber auch das ist nicht sonderlich wichtig an dieser Stelle. Wollte das nur schon mal vorweg nehmen falls die Frage aufkommt.

Frameworks? Nein danke!

Ich mag sie nicht diese Frameworks (Bsp.: Bootstrap / Foundation). Sie geben mir das Gefühl, dass ich mir eine 999 Teile Werkzeugkiste gekauft habe aber eigentlich nur einen Satz Inbusschlüssel benötigte. In der Anleitung (Dokumentation) steht dann ganz sicher auch noch, wie ich etwas zu benutzen habe und warum das alles so super durchdacht ist. Nein, ich möchte den Frameworks auf keinen Fall ihre Bedeutung absprechen. Aber für mich sind sie eher eine Qual als die erste Wahl. CSS Code rocken, dass möchte ich und das kann ich, ein wenig zumindest! :)

Media Queries für bestimmte Geräte? Nein!

Ansage! Um gleich etwas den Wind aus den Segeln zu nehmen. Natürlich kann es hier und da Sinn machen, dass man gezielt ein Gerät ansprechen möchte. Oder auch eine Geräteklasse (High Resolution Devices (Retina)). Das ist auch OK und sollte man dann auch machen. Aber in erster Linie sind die Media Queries dazu da Probleme in der Darstellung zu lösen oder Inhalte anders darzustellen bzw. anders zu formatieren. Das macht man aber sicher nicht vom Gerät abhängig sondern vom Inhalt, also dem was man zeigen möchte. Auf jedes Gerät einzugehen kann man heute gar nicht mehr gewährleisten, da es einfach zu viele sind. Solche Beispiele hier: “CSS Media Queries for iPads & iPhones” führen aus meiner Sicht zu nichts. Außer man möchte wie gesagt wirklich gezielt etwas machen.

Ein Gutes Beispiel hierfür wäre die Website von Heiko, der einfach möchte, dass man sein Smartphone ins Querformat dreht (Oder einfach den Browser breiter zieht) und weiter gehts.

Im Grunde sagt er dem User: Diese Website ist für Geräte gemacht, die mindesten 480px in der Breite darstellen können bzw. dessen Browser mindestens diese Breite darstellen kann. Das macht er einfach so:

      
        @media only screen and (max-width: 479px) {
  #turn-me {
    display: block !important;
  }
}

Alles was nicht mindestens 480px in der Breite darstellen kann oder genauer gesagt: alles was maximal als 479px Breite darstellen kann bekommt den Layer “#turn-me” zu sehen.

Geräte direkt ansprechen sollte also eher die Ausnahme sein.

Fixe Breakpoints? Nein! Wenn doch dann bitte nicht darauf versteifen!!

Es ist ja fast schon ein kleiner Standard der sich hier zeigt wenn man auch so sieht wie Frameworks arbeiten. Egal ob Adaptive oder Fluid. Breakpoints haben sie alle und brauchen sie auch alle. Heute sieht das dann so aus, dass wir so ein kleines Set haben, die Defaults quasi. Ein Beispiel dafür (das normale CSS wäre alles was breiter ist also 1280px):

      
        /* Kann maximal 1280px darstellen. */
@media only screen and (max-width : 1280px) {
  /* CSS hier */
}
 
/* Kann maximal 1024px darstellen. */
@media only screen and (max-width : 1024px) {
  /* CSS hier */
}
 
/* Kann maximal 768px darstellen. */
@media only screen and (max-width : 768px) {
  /* CSS hier */
}
 
/* Kann maximal 568px darstellen. */
@media only screen and (max-width : 568px) {
  /* CSS hier */
}
 
/* Kann maximal 320px darstellen. */
@media only screen and (max-width : 320px) {
  /* CSS hier */
}

So könnte also ein Set von Media Queries aussehen, wo wir dann alles reinschreiben werden, was wir anpassen wollen. Wie ihr seht orientieren sich die Breiten schon an gewissen Geräten bzw. dessen Auflösungen aber es ist nicht genau auf ein Gerät zugeschnitten. Wie gesagt haben wir jetzt ein Set und damit sollte man doch alles machen können… Nein! Man kann sicher sehr viel damit machen aber eben nicht alles.

Wenn wir mit dem oben genannten arbeiten würden, würden wir oft gut dastehen aber es wird Fälle geben, wo diese Breakpoints nicht greifen bzw. nicht richtig greifen. Sei es weil zu große Sprünge zwischen den einzelnen Breakpoints vorhanden sind oder oder weil sich vielleicht einfach nur die Sprache der Website ändert. Was im englisch noch super war, ist im französischen nun nicht mehr so super. Ja so lange Wörter haben schon so manches Layout zerschossen. Ein paar Beispiele die das Probleme zeigen anhand der Circle Conference Website:

Hier in Abb. 01 ist alles gut im Speaker / Panel Bereich:

Cc 2480 1200X2010
Abb. 01: Circle Conference 2480px breit

Hier in Abb. 02 ist soweit auch noch alles gut im Speaker / Panel Bereich. Die Texte werden aber unten schon Teilweise sehr eng:

Cc 1600 1200X2595
Abb. 02: Circle Conference 1600px breit

Hier in Abb. 03 brechen die Boxen schon das erste mal um im Panel Bereich und sind jetzt nur noch zwei Spalten statt 3. Dennoch werden die Texte schon wieder sehr nah an den Rand getrieben:

Cc 1024
Abb. 03: Circle Conference 1024px breit

Hier in Abb. 04 Hier wird bei den Speakern schon etwas Text abgeschnitten. Auch beim Rest ist es wieder eng was den Platz angeht:

Cc 768
Abb. 04: Circle Conference 768px breit

Hier in Abb. 05 Texte sind an vielen Stellen abgeschnitten und es gibt auch unten den ersten Darstellungsfehler der Boxen:

Cc 568
Abb. 05: Circle Conference 568px breit

Hier in Abb. 06 Ein neuer Umbruch. Wieder alles gut:

Cc 480
Abb. 06: Circle Conference 480px breit

Media Queries direkt zu den Modulen / Elementen!

Was? Meint er das jetzt ernst? Mein CSS File wird doch dann viel größer durch ständige Media Queries. Ganz ehrlich? Ob mein CSS File 10 KB oder 50 KB ist wird bei den meisten Websites heute nicht die entscheidende Rolle spielen. Es wird das kleinste Übel sein. Natürlich war das auch etwas Übertreibung von 10 KB auf 50 KB. Letztendlich wird es verschwindend gering sein. Vielleicht in manchen fällen sogar weniger als mit der anderen Methode (Fixe Breakpoints).

Als erstes hab ich ein kleines Sass Mixin dafür — ja wir arbeiten hier jetzt mit Sass — was mir Sascha Fuchs gebaut hat, danke! Das sieht dann so aus:

      
        // Media Query
$media-direction: max;
@mixin breakpoint($values,$direction: $media-direction) {
 
  @if length($values) > 1 {
    $min: nth($values,1);
    $max: nth($values,2);
 
    @if unitless($max) {
      $max: $max + 0px;
    }
 
    @if unitless($min) {
      $min: $min + 0px
    }
 
    @media screen and (min-width: $min) and (max-width: $max) {
      @content;
    }
 
  } @else {
 
    @if unitless($values) {
      $values: $values + 0px;
    }
 
    @media only screen and (#{$direction}-width: $values) {
      @content;
    }
  }
}

Im Grunde gebe ich in der ersten Variable $media-direction nur an, ob ich mit min-width oder max-width arbeiten möchte. Bei mir, wie oben schon gesagt, wird esmax-width sein. Der Rest sind ein paar If Abfragen und verschiedene Ausgaben die damit verbunden sind. Ob Einheiten vorhanden sind. Ob ein oder zwei Werte übergeben wurden... An der Stelle auch nicht wichtig. Bei Fragen dazu gibt es ja die tolle Kommentarfunktion.

Hier mal ein ganz simples Beispiel von einer Liste mit den Media Queries direkt am Element:

      
        ul {
  width: 100%;
  max-width: 1280px;</p>
 
  li {
    float: left;
    width: 25%;
    font-size: 60px;
    padding: 40px;
    line-height: 1.5;</p>
 
    @include breakpoint(1024) {
      width: 33.333333%;
      font-size: 50px;
    }
 
    @include breakpoint(568) {
      width: 50%;
    }
 
    @include breakpoint(480) {
      width: 100%;
      font-size: 40px;
    }
  }
}

Was passiert ist nicht sonderlich spannend. Spannender ist es wie wir die Media Queries eingebracht haben. Wir könnten die ganzen Regeln jetzt hier wegholen und in unsere fixen Breakpoints einteilen. Damit hätten wir drei entscheidende Nachteile und aus meiner Sicht keinerlei Vorteile…

  1. Wir ruinieren uns die Übersicht, in dem wir das was zusammen gehört, ganz weit voneinander entfernen. Vielleicht in verschiedene Dateien sogar. Wie auch immer... Dadurch wird das ganze deutlich komplizierter beim Arbeiten. Ständig Dateien wechseln oder dauernd suchen… Anstrengend und wenig produktiv!!!
  2. Wartung oder Erweiterung einzelner Elemente. Das spielt auch mit rein, dass wir dann wieder zu sehr an unsere fixen Breakpoints gebunden sind bzw. wir immer wieder neue anlegen müssten. Nur weil vielleicht ein Modul diesen braucht. Da sind wir auch schon beim Punkt. Mit der oben gezeigten Methode habe ich zwar auch meine gewissen Fixpunkte aber bleibe dennoch flexibel. Wenn ich irgendwo ein Zwischenschritt benötige und sei es nur um eine kleine Eigenschaft anzupassen, kann ich das ohne große Probleme machen.
  3. Lesbarkeit des Codes!!! In dem Beispiel oben wird sofort klar, was wann passiert. Ein anderer Entwickler wird keinerlei Probleme haben, das Beispiel von oben zu verstehen und gegebenenfalls anzupassen. Ist das ganze zerstreut wird das deutlich schwieriger in der Lesbarkeit und das führt auch zum schlechteren verstehen. Auch wird man hiermit so gut wie unmöglich Code doppelt schreiben, da man es im Blick hat und nicht wild hin und her kopiert.

Das schwierige ist nicht die Website an gewissen Breakpoints gut aussehen zulassen sondern in den Bereichen dazwischen. Dort trennt sich die Spreu vom Weizen. Eine responsive Website sollte lückenlos sauber funktionieren.

Es gibt sicher keinen richtigen Weg, wie man sein CSS Code schreiben sollte. Jeder hat hier seine Vorlieben und das ist auch gut so. Ich finde es sehr interessant die verschiedenen Ansätze zu sehen und darüber zu lesen. Mit den paar Worten oben wollte ich meinen Senf dazu geben, speziell im Bezug auf Media Queries. Mich lässt dieser Weg fokussiert an einer Sache arbeiten. Auch bin ich bisher den Ansatz gefahren, dass ich den responsive Part zum Schluss mache. Hat sich bei der anderen Methode einfach mehr angeboten. Da habe ich alles fertig gemacht und hab dann den kompletten CSS-Code kopiert und bei den Media Queries eingefügt. Dann wurde Stück für Stück angepasst und überflüssiges wieder gelöscht. Im Nachhinein ziemlich umständlich.

Jetzt wird einfach ein Modul direkt von oben nach unten durchgearbeitet und später nur noch kleine Anpassungen gemacht. Alles in allem auch hier produktiver aus meiner Sicht und weniger Fehleranfällig.

Development
Tags breakpoints css development media queries responsive sass scss
comments powered by Disqus

Maybe interesting…

UP