CSS Feature Queries – @supports ()
In diesem Beitrag lernt ihr die CSS Feature Queries anhand eines anschaulichen Beispiels kennen.
Wenn man herausfinden möchte welche Technologien von einem Browser unterstützt werden, führt der Weg häufig zum Hilfsmittel Modernizr. Das JavaScript-Framework schreibt u.a. CSS-Klassen in den <html>
-Tag der Website von denen anschließend moderne Funktionen abhängig gemacht werden können. Diese Vorgehensweise ist im Moment gängige Praxis.
Alternativ zu einer JavaScript-basierten Lösung wie Modernizr könnt ihr auch das CSS Feature Query @supports ()
einsetzen um in Erfahrung zu bringen, welche CSS- und JavaScript-Techniken im Browser verwendet werden können. In diesem Beitrag möchte ich die CSS-Abfrage anhand zweier anschaulicher Beispiele erklären.
Die Basis-Version
Die Beispiel-Website verwendet einen Header, eine Navigationsleiste und einen exemplarischen Inhaltsbereich, der nur dazu dient die Seite scrollbar zu machen. Im Idealfall wird die Navigationsleiste unter dem Header positioniert und verhält sich »sticky«. Sie bleibt also am oberen Ende des Browserfensters kleben, sobald man den Header weggescrolled hat.
Wir entwickeln das Beispiel nach dem Progressive-Enhancement-Konzept und beginnen mit der schlechtesten denkbaren Variante: Der Browser versteht weder den Befehl position:sticky;
, noch die @supports ()
-Abfrage. In diesem Fall befindet sich die Navigation unter dem Header, beide Elemente sind grau eingefärbt und scrollen ganz normal (position: static;
).
In den nächsten Schritten optimieren wir diese Basis-Darstellung für modernere Systeme.
@supports ()
Nun kommt das Feature Query @supports ()
in Spiel. Mit Hilfe von @supports ()
können wir überprüfen ob ein Browser eine bestimmte Eigenschaft-Wert-Kombination unterstützt. Die Funktion nach der wir fragen wollen, wird in den runden Klammern notiert. Achtet darauf, dass kein Semikolon am Ende notiert wird!
Mit folgendem CSS-Code überprüfen wir, ob der Browser position: sticky
versteht. Wenn ja, nutzen wir die Funktion, färben Header und Navi grün ein und wissen auch, dass der Browser @supports ()
versteht.
@supports (position: sticky) {
.site-header {
background: #9fe566;
}
.site-nav {
position: sticky;
background: #79c140;
}
}
@supports not ()
Nun fügen wir noch einen Zwischenschritt ein, der in der Praxis vielleicht nicht zwingend notwendig ist, aus didaktischen Gründen in diesem Beispiel aber nicht fehlen sollte. Mit Hilfe von @supports not ()
können wir prüfen, ob der Browser den position:sticky;
-Wert nicht unterstützt.
Sofern der Browser die Sticky-Funktion nicht versteht, färben wir alles rot ein und positionieren die Navigation mit position:fixed;
immer ganz oben im Browser.
@supports not (position: sticky) {
.site-header {
background:#e56666;
height:360px;
}
.site-nav {
position: fixed;
width:100%;
background:#c03535;
}
}
Live-Beispiel – Fixierte Haupnavigation
Zum Veröffentlichungszeitpunkt dieses Artikels sind Safari, Firefox und Chrome die idealen Kandidaten um das Beispiel zu testen. Firefox versteht alle notwendigen Techniken, Chrome nur Teile davon. Safari versteht nichts.
Alternatives Beispiel – Silbentrennung & Blocksatz
Anhand eines zweiten Beispiels kann der Praxisnutzen noch besser vermittelt werden. Mit Hilfe von @supports prüfen wir, ob der Browser Silbentrennung unterstützt. Wenn ja, setzen wir den Text auf Blocksatz und aktivieren die Silbentrennung.
@supports (hyphens: auto) {
body {
text-align:justify;
hyphens: auto;
}
}
Feature Queries mit »and« und »or« kombinieren
Es ist auch möglich Abfragen zu kombinieren. Dazu werden die Schlüsselwörter and
oder or
verwendet. Mit or
könnt ihr prüfen, ob eine der nachfolgend notierten Eigenschaften unterstützt wird. Die or
-Abfrage ist vor dem Hintergrund verschiedener Browser-Präfixe besonders interessant.
@supports (box-shadow: 0 2px 1px rgba(0,0,0,0.3)) or
(-moz-box-shadow: 0 2px 1px rgba(0,0,0,0.3)) or
(-webkit-box-shadow: 0 2px 1px rgba(0,0,0,0.3)) {
.selector {
-moz-box-shadow: 0 2px 1px rgba(0,0,0,0.3);
-webkit-box-shadow: 0 2px 1px rgba(0,0,0,0.3);
box-shadow: 0 2px 1px rgba(0,0,0,0.3);
}
}
Mit and
kann geprüft werden ob mehrere Eigenschaften unterstützt bzw. nicht unterstützt werden. Das ist vor allem dann interessant, wenn der gewünschte Effekt von mehreren CSS-Eigenschaften abhängig ist. Es übrigens nicht erlaubt and
und or
zu kombinieren.
@supports (-webkit-filter: blur(2px)) and (transition:all 1s ease-in-out) {
img:hover {
-webkit-filter: blur(2px);
transition:all 1s ease-in-out;
}
}
Browser-Support für CSS Feature Queries
Der Browser-Support sieht zum Veröffentlichungszeitpunkt dieses Artikels durchwachsen aus. Firefox, Chrome und Opera können Feature Queries interpretieren, der Internet Explorer und Safari nicht. Den detaillierten Browser-Support könnt ihr hier einsehen.
Wie funktioniert es denn, dass man überprüft, ob der Browser das Grafikformat avif unterstützt und dann im Falle der Unterstützung eine entsprechende Anweisung oder Regel erstellt?
Mit @supports fragst du nach CSS-Features. Kompatibilität mit Bildformaten kannst du u.a. mit .
Vielen Dank Jonas für deine Antwort.
Ich möchte als Hintergrundbild eine Grafik im avif-Format, falls dieses Format vom Browser unterstützt wird, andernfalls soll ein jpg-Bild angezeigt werden, aber das funktioniert wohl nur über ein Skript. Zumindest habe ich noch nichts anderes gefunden.
In den oben genannten Beispielen färbt sich der Hintergrund je nach verfügbarer Funktion.
Ist es mit dieser Technik auch möglich dass sich die Hintergrundfarbe erst ändert wenn das Menü per Sticky Befehl am Displayrand andockt?
@Hans
Warte einfach ab bis Windows 10 erscheint dann fängt eh der nächste Browserkrieg an, der was auch für den einen oder anderen Browser blutig enden kann.
ich hoffe wirklich das microsoft mit spartan endlich mal etwas aufrückt was w3c features angeht … :-P . als webdesigner kann man diese firma echt nur verfluchen.
gute Übersicht, aber leider ist @supports noch nicht zu gebrauchen. Gerade bei dem Beispiel mit position: sticky; ist es so, dass der Safari das mit Präfix unterstützt, aber @supports nicht unterstützt. Heißt Safari würde den Fallback bekommen. So lange noch Modernizr nehmen.
Man müsste halt bei
@supports
mitor
auch die Präfixe prüfen. Aber ich gebe dir recht – wir müssen noch ein wenig warten bis es in Kundenprojekten einsetzbar ist.Danke für die Einführung! Persönliches Fazit: noch nicht einsatzbereit. In den Browsern, in denen man es hauptsächlich bräuchte (den mobilen nämlich, und IE), fehlt das Feature fast durchgängig. Also erstmal weiter Modernizr, bis der Support für @support supportiger wird … ;)