Die CSS Conditionals 5 Spezifikation entwickelt sich. Aber sie haben ein Problem: SASS

Wer SASS kennt, weiß es: Man kann – auf dem Server, zur Generierungszeit – Bedingungen formulieren und damit beispielsweise steuern, welche CSS-Variante ein Mixin erzeugt. Das Schlüsselwort, das SASS dafür verwendet, heißt @if – und damit wildert es im Wald der generellen Syntax für @-Regeln, die CSS im Browser verwendet.

Das war lange unkritisch, aber das W3C entwickelt seit ein paar Jahren an der Stufe 5 von CSS-Bedingungen (CSS Conditionals Level 5). Die bisherigen Stufen brachten uns @media-Queries für Medientypen und Medienfeatures, sowie @supports-Abfragen für Eigenschaften und Selektoren.

Mit Stufe 5 wird @supports um Abfragen für Font-Technologien und Font-Formate erweitert. Die zugehörige Syntax lautet

   @supports font-tech(name) { ... }
   @supports font-format(format) { ... }

Als Format können diejenigen Formate angegeben werden, die in der format()-Angabe der src-Eigenschaft einer @font-face Definition zulässig sind, also beispielsweise woff2, truetype oder eot.

Font-Technologien sind etwas, was in Abschnitt 11 der CSS Fonts 4 Spezifikation beschrieben wird. Wenn Sie Spezialfonts verwenden wollen, die besondere Technologien verwenden, dann sollte sich bei dem jeweiligen Font ein Hinweis auf diese Technologien finden. Wenn nicht, dann sind diese Abfragen für Sie ohne Belang.

Und was hat es nun mit SASS auf sich?

Die dritte Neuerung, die uns CSS Conditionals 5 bringen wird, ist eine Zusammenführung von @media- und @supports-Abfragen in eine generelle Abfragesyntax, die auch Abfrageketten und einen Defaultzweig ermöglicht. Also das, was Programmierer schon längst als

if (bedingung)
   ...
else if (bedingung)
   ...
else
   ...

kennen.

Und hier liegt die Crux: Die Spezifikation verwendet eine @-Regel Syntax, aber @if ist bereits von SASS reserviert worden. Würde natives CSS nun ein @if einführen, so wäre entweder SASS gezwungen, dem Präprozessor genug Intelligenz einzuhauchen, um ein SASS-@if von einem CSS-nativen @if zu unterscheiden – oder alle SASS-Quellen müssten von @if auf ein @-sass-if oder etwas ähnliches umsteigen.

Weil SASS eine gewaltige Verbreitung hat, wollte man das vermeiden. Die Spezifikation verwendet statt @if deshalb eine Syntax mit @when:

@when bedingung {
   ...
}
@else bedingung {
...
}
@else {            /* Default-Fall */
   ...
}

Als Bedingung kommt eine Syntax zum Einsatz, wie sie für @supports eingeführt wurde. Für die bisherigen Abfragen auf Medienfeatures und unterstützte Eigenschaften werden die Pseudofunktionen media() und supports() eingeführt. selector(), font-format() und font-tech() wird von @supports übernommen:

@when media(width > 50em) 
@when supports(background-music:url(foo.wav))
@when selector( body:has(:passive) )
@when font-format(woff2)
@when font-tech(color-COLRv0)

Die Abfragen auf background-music und :passive sollten in aktuellen Browsern natürlich fehlschlagen…

Das lässt sich auch mit AND und OR kombinieren, die Spec enthält dieses Beispiel:

@when media(width >= 400px) and media(pointer: fine) and supports(display: flex) {
  /* A */
}
@else supports(caret-color: pink) and supports(background: double-rainbow()) {
  /* B */
}
@else {
  /* C */
}

Das ist ziemlich großartig, und erspart uns umständliche Doppelabfragen auf width > 50em und width <= 50em. Her damit, sag ich!

Womit man aber nicht gerechnet hatte, war der Aufschrei der Community. Wie man denn auf die Idee käme, das so naheliegende @if zu verwerfen, und einen Kniefall vor einem dahergelaufenen Toolfuzzi zu machen? „Tools kommen und gehen, Standards sind für die Ewigkeit“, wurde angeführt, also habe sich doch SASS gefälligst zu bewegen und der Spec Platz zu machen. Und weil die Änderung nicht die Benutzer, sondern die Autoren betrifft, ist das doch alles kein Thema. Schnell mal den Replace auf die Codebasis, SASS updaten, und gut ist. Höre ich da ein leises Mimimi? Pah! Nun gut, Lea Verou hat es freundlicher formuliert.

Das ignoriert natürlich den Umstand, dass SASS nicht irgendein zusammengefrickeltes Tool mit 13 Anwendern ist. Es ist 4 Jahre älter ist als der erste CSS-3 Draft, der @media-Featurequeries und eine @supports-Regel einführte. Bei SASS kam damals niemand auf die Idee, dass 2021 ein erster Working Draft für CSS-Bedingungen mit @when (oder @if oder @on oder @case oder was auch immer) veröffentlicht werden würde. Und es ignoriert den Umstand, dass der größte Teil professionell erstellter Webseiten CSS Präprozessoren wie SASS verwendet. Das Mimimi wäre also eher ein Hurrikan.

Gut, die Diskussion zu @if vs @when ist etwa 5 Jahre älter, wie Tab Atkins in einem der Zank-Threads zu diesem Thema schrieb, aber dennoch kann man von SASS nicht erwarten, so weit in die Zukunft zu schauen. Viellecht hätte man erwarten können, dass SASS nicht den "Namensraum" der @-Regeln in Beschlag nimmt und %-Regeln statt @ Regeln verwendet. Die Diskussionen dazu wirken allerdings teilweise so, als ginge es vor allem ums Rechthaben, und nicht darum, eine praktische Lösung zu finden.

Werden wir nun als Partner für @else ein @when bekommen? Oder doch ein @if? Werden SASS-User einen globalen Search&Replace auf ihre Codebasis machen müssen, um @if durch @-if zu ersetzen? Oder gar eine Option, um @if durch %if zu ersetzen? In den Diskussions-Threads ist es stiller geworden, und bislang steht in der CSS Conditionals 5 Spec immer noch ein @when.

Aber bisher hat es auch noch kein Browserhersteller unternommen, mit der Implementierung zu beginnen. Bei Chromium, Mozilla und Webkit existieren Implementierungstickets, aber bei keinem steht etwas von "Arbeit begonnen". Wir können uns nur wünschen, dass der Streit bald geklärt wird und @else endlich erfährt, wozu sie die Alternative liefern darf.

Quellen

• CSS Conditionals Level 5 Spezifikation
• Kingsley Lubahn auf blog.logrocket.com: Extending CSS when/else chains: A first look
• Tab Atkins erste Idee zu @when und @else und eine Diskussion dazu.
• Sie führt zum Streit um's @when – Lea Verou vs Tab Atkins (Google) und Natalie Weizenbaum (SASS)