“Modulares CSS” ist ein Keyword das in letzter Zeit in der Webbranche immer häufiger fällt. Neben modularem Programmcode ist es nun auch gang und gebe den CSS Code so “modular”, sprich wiederverwendbar und effizient wie nur möglich zu schreiben. Da es sich bei CSS aber grundsätzlich um eine statische Sprache handelt, gibt es so genannte CSS Preprozessoren, die es ermöglichen, dynamischen CSS Code zu erstellen. Die gängigsten CSS Preprozessoren sind LESS, welches nun auch in der neuesten Bootstrap Version integriert ist, und Sass.

Der Ansatz von modularem CSS Code umfasst die Theorie, dass einzelne Teile des Codes in anderen Projekten leicht wieder verwendet werden können und leicht erweiterbar sind. So sollen die einzelnen Teile (meistens Module genannt) unabhängig in Größe, Breite und Verhältnissen zu anderen Teilen sein.

/* modulares Element (module.css) */

.box {
    width: 100%;
    height: 100%;
    border-radius: 5px;
    border: 2px solid;
    padding: 20px;
}

/* stylen des Elements in einem Projekt (theme.css) */

.box {
    border-color: green;
    margin: 20px;
    background-color: white;
}

Will man nun dieses Element in verschiedenen Größen anpassen, so gibt es die Möglichkeit, die Media Queries gleich nachgestellt im Code einzufügen. Was zwar zu Redundanz führt, aber den Code übersichtlicher gestaltet.

/* modulares Element (module.css) */

.box {
  width: 100%;
  height: 100%;
  border-radius: 5px;
  border: 2px solid;
  padding: 20px;
 }

@media screen and (max-width: 320px){
 .box {
  border: 1px solid;
  padding: 5px;
  }
}

@media screen and (max-width: 640px){
 .box {
  padding: 10px;
  }
}

/* … weitere Media Queries für andere Größen würden folgen … */

Mit Sass kann man nun das ganze schon etwas übersichtlicher gestalten:

$small: "max-width: 320px";
$medium: "max-width: 640px";

.box {
  width: 100%;
  height: 100%;
  border-radius: 5px;
  border: 2px solid;
  padding: 20px;

  @media screen and #{$small}{
    border: 1px solid;
    padding: 5px;
  }

  @media screen and #{$medium}{
    padding: 10px;
  }

}

Das neue Release von Sass 3.2 bringt eine praktische Neuerung für die Benützung von Breakpoints mit sich. Über ein einziges Mixin (ähnlich einer Funktion) und einem Übergabeparameter kann man Breakpoints für verschiedene Auflösungen steuern. Der Code wird dadurch kompakter und übersichtlicher.

/* Breakpoints */

$small: 320px;
$large: 1280px;

/* Einmalige Deklaration zu Beginn des CSS Codes */

@mixin breakpoint-form($size) {
   @if $size == small-screen {
    @size only screen and (max-width: $small) { @content; }
   }
   @else if $size == medium-screen {
    @size only screen and (min-width: $small + 1) and (max-width: $large - 1) { @content; }
   }
   @else if $size == large-screen {
    @size only screen and (min-width: $large) { @content; }
   }
}

.box {

   width: 100%;
   height: 100%;
   border-radius: 5px;
   border: 2px solid;
   padding: 20px;
   @include breakpoint-for(small-screen) {border: 1px solid; padding: 5px};
   @include breakpoint-for(medium-screen) {padding: 10px};

}

.other-box {

   border-radius: 10px;
   padding: 30px;
   @include breakpoint-for(small-screen) {border-radius:0;};

}

Optimal wäre natürlich wenn der kompilierte Sass Code dann alle benützten includes zu einem einzigen Media Query zusammenfügen würde. Jedoch ist dieses Feature noch nicht integriert. So bekommt man als CSS Ausgabe einen ziemlich unübersichtlichen Code. Dieses Feature ist bereits bei Sass reported und wird hoffentlich mit dem nächsten Release mitkommen.

/* wünschenswerter kompilierter Code */

@media screen and (max-width: 320px) {
  .box {
    border: 1px solid;
    padding: 5px
  }
  .other-box {
    border-radius:0;
  }
 }

/* tatsächlich kompilierter Code */

@media screen and (max-width: 320px) {
 .box {
   border: 1px solid;
   padding: 5px
 }
}

@media screen and (max-width: 320px) {
  .other-box {
    border-radius:0;
  }
}

 Vor- & Nachteile

Wenn man also die Media Queries direkt bei den einzelnen Modulen mit Sass in den Code integriert kann es einige Vorteile bringen:

• Die Breakpoints können schnell geändert werden (Variablen)
• Der Code wird für den Programmierer übersichtlicher, da das Verhalten der einzelnen Teile in den unterschiedlichen Auflösungen auf einmal ersichtlich ist.
• Man erspart sich das ständige Wechseln zu unterschiedlichen Files (responsive.css).

Jedoch kann diese Art und Weise des Codings auch seine Nachteile mit sich bringen:

• Der kompilierte Code kann sehr unstrukturiert werden.
• Es kann schwierig sein für einen anderen Programmierer, sich in diese Schreibweise einzulesen.
• Der Code wird teilweise redundant, wegen den Wiederholungen der Media Queries, was eigentlich ein Bruch mit einer Grundsatzregel der Modularität ist.
• Man läuft Gefahr, die Breakpoints im Vorhinein zu definieren und so das Design nach den Breakpoints zu machen, und so den responsive “Flow” zu unterbrechen.

Fazit

Grundsätzlich kommt es auf die Art des Projekts und auf die Vorliebe der Teammitglieder an. Auf jeden Fall ist es einen Versuch wert diese Schreibweise auszuprobieren. Besonders bei kleineren Projekten habe ich Gefallen an diesen Media Queries gefunden, da man nur eine begrenze Menge an Breakpoints benützt und so schnell und auf eine übersichtliche Art und Weise responsive Websites erstellen kann.