Das mächtige Ampersand in Sass

Was macht das “&” in Sass? Es referenziert das Parent-Element und ermöglicht damit das effiziente “mergen” von Selektoren.

Beispiel:

.hund {
  background-color: #444;
  &:hover {
    display: none;
  }
  &.bissig {
    display: block;
  }
}

Dies wird kompiliert zu:

.hund {
  background-color: #444;
}
.hund:hover {
  display: none;
}
.hund.bissig {
  display: block;
}

So weit, so gut, so praktisch.

Man kann das Ampersand natürlich auch statt am Anfang am Ende positionieren und erhält damit eine weitere Möglichkeit sein CSS gut zu strukturieren und vor allem Don’t repeat yourself einzuhalten. Besonders praktisch ist das z.B. im Einsatz mit modernizr und generell mit state-handling durch Klassen an übergeordneten Elementen. Ein Beispiel:

.btn {
  font-size: 1em;
  .no-touch &:hover {
    border: 1px solid #000;
  }
}

Das wird kompiliert zu:

.btn {
  font-size: 1em;
}
.no-touch .btn:hover {
  border: 1px solid #000;
}

Wunderbar! Dies lässt sich auch wunderbar in Mixin einsetzen und das Ampersand wird damit zu einem mächtigen Werkzeug.

Ein weiteres Beispiel, das doppelte Ampersand

.col-1of2 {
  color: #666;
  & + & {
    margin-left: 30px;
  }
}

Dies wird kompiliert zu:

.col-1of2 {
  color: #666;
}
.col-1of2 + .col-1of2 {
  margin-left: 10px;
}

I <3 ampersand in Sass

Designing for access

Zum Aspekt der Usability einer Webseite gehört u.a. das Designen der Webseite für varierende Bildschirmgrößen (RWD) als auch das Behandeln der unterschiedlichen Eingabemethoden (Touch, Click). Aber wir sollten auch darauf achten, das unsere Webseite auch in weniger idealen Bedingungen (Screenreader, limitierte Software beim Zugriff auf das Web) funktional bleibt. Einer der großen Stärken von HTML ist zum Beispiel die großartige backward compatibility, was bedeutet das Seiten die mit der letzten Version von HTML geschrieben wurden, weiterhin auf nahezu allen Geräten aufgerufen werden können, die HTML unterstützen.

Während HTML Dokumente weitestgehend zugänglich geboren wurden bleiben sie dies nicht immer: Der (rücksichtslose) Einsatz von CSS und JavaScript kann dazu führen das vorher zugänglicher Inhalt im Nachhinein vollkommen unzugänglich ist.
Nehmen wir zum Beispiel ein Drop-Down Menü dessen Inhalt mit “display: none” versteckt wurde. Mit wenigen Ausnahmen werden Screenreader nur die Teile der Webseite vorlesen die auch sichtbar sind. So wird das Menü nicht nur visuell versteckt, sonder auch akustisch.

Die Idee dass das Web zugänglich geboren wurde geht ein hand mit dem Konzept des Progressive Enhancement, das uns lehrt zuerst mit funktionierendem, bedeutungsvollen HTML zu beginnen und dann “unauffällig” die User Experience mit dem Präsentationslayer (CSS) und dem Funktionslayer (JS) zu bereichern.
Aus großer Kraft folgt große Verantwortung, immer dann wenn wir uns ins Abenteuer des nicht-standard-browser rendern von HTML begeben sind wir dafür verantwortlich dass die Inhalte weiterhin zugänglich bleiben.
Ein gutes Beispiel dafür sind die neuen tollen Formular Input types wie “number, color oder search”. Wir können diese Features sicher nutzen um in Browsern die diese Typen schon unterstützen eine bessere Interaktion zu ermöglich aber damit auch weiterhin Browser unterstützen die diese Typen nicht kennen und stattdessen auf ein Standard-Text Element zurückfallen.

Ein weiterer Bestandteil des Designen für Accessbility sind die Beachtung der ARIA-Spezifikationen (W3C’s Accessible Rich Internet Applications) welches ein Set von HTML-Attributen ist um erweiterte Bedeutung den HTML-Elementen zuzuweisen.

Das Designen für Accessibility erfordert vor allem 2 Sachen, zum einen ein bisschen Planung und vor allem die Erkenntnis das es Millionen von Internetnutzern gibt, die zum einen ggf. selbst eingeschränkt sind oder deren Geräte / Software eingeschränkt ist.

Zugänglichkeit für alle!