„Funktioniert das eigentlich in Safari?" – diese Frage stellen sich Webentwickler täglich. Can I Use ist die Standardantwort darauf. Die Website zeigt für nahezu jedes HTML-, CSS- und JavaScript-Feature eine farbcodierte Tabelle, die angibt, welche Browserversionen das Feature unterstützen, welche es hinter einem Flag verstecken und welche es schlicht nicht kennen. Dieser Artikel erklärt, wie man die Daten richtig liest, welche Browser man 2026 noch unterstützen sollte und wie man mit Polyfills und Build-Tools gezielt auf Lücken reagiert.
Was ist Can I Use und warum ist es unverzichtbar?
Can I Use wurde 2010 von Alexis Deveria gestartet und ist seitdem zur zentralen Referenz für Web-Kompatibilitätsdaten gewachsen. Die Datenbasis wird aus offiziellen Browser-Changelog-Quellen, MDN-Daten und der Community aktuell gehalten. Das Tool beantwortet die Frage: „Ab welcher Version unterstützt Browser X das Feature Y?"
Ohne Can I Use riskiert man Folgendes: Man setzt ein modernes CSS-Feature produktiv ein, das in einem Browser mit 8 % Marktanteil komplett bricht. Das kann zu weißen Seiten, kaputten Layouts oder funktionslosen Formularen bei einer erheblichen Nutzergruppe führen – und das merkt man in der Entwicklungsumgebung oft gar nicht, weil man selbst Chrome oder Firefox verwendet.
Die Oberfläche: Unterstützungstabellen richtig lesen
Nach der Sucheingabe eines Features zeigt Can I Use eine horizontale Tabelle mit Spalten für jeden Browser (Chrome, Firefox, Safari, Edge, Opera, iOS Safari, Samsung Internet usw.) und Zeilen für verschiedene Versionen. Die Farben haben folgende Bedeutung:
- Grün – vollständige Unterstützung
- Gelb/Orange – Teilunterstützung oder benötigt Vendor-Prefix
- Rot – keine Unterstützung
- Grau – unbekannt oder nicht zutreffend
Über der Tabelle steht die globale Unterstützungsrate in Prozent – berechnet aus den aktuellen Browser-Marktanteilen. Darunter findet man detaillierte Hinweise: Einschränkungen der Implementierung, bekannte Bugs in bestimmten Versionen und Links zu relevanten MDN-Einträgen.
Browser-Marktanteile 2026: Welche Browser sollte man unterstützen?
| Browser | Desktop-Anteil | Mobile-Anteil | Empfehlung |
|---|---|---|---|
| Chrome (inkl. Android) | ~65 % | ~63 % | Immer unterstützen |
| Safari (inkl. iOS) | ~11 % | ~25 % | Immer unterstützen |
| Edge | ~11 % | ~1 % | Immer unterstützen |
| Firefox | ~7 % | ~1 % | Unterstützen empfohlen |
| Samsung Internet | – | ~5 % | Testen empfohlen |
| IE 11 | <0,5 % | – | Nicht mehr unterstützen |
Eine praktische Daumenregel: Features mit einer globalen Unterstützung über 95 % können in der Regel ohne Fallback eingesetzt werden. Zwischen 85 % und 95 % sollte man prüfen, ob ein graceful degradation (das Feature fehlt, aber die Seite bleibt nutzbar) oder ein Polyfill sinnvoll ist. Unter 85 % braucht man entweder einen Polyfill oder muss auf das Feature verzichten.
Wichtige CSS-Features mit schlechter Unterstützung
Einige moderne CSS-Features sind trotz ihrer Nützlichkeit noch nicht überall verfügbar:
- Container Queries (
@container): Inzwischen in allen modernen Browsern unterstützt (Chrome 105+, Firefox 110+, Safari 16+). IE und ältere Safari-Versionen kennen es nicht. Für alte iOS-Geräte kann ein Polyfill nötig sein. :has()Selektor: Der „Parent-Selektor" funktioniert seit Safari 15.4, Chrome 105 und Firefox 121. Ältere Firefox-Versionen (vor 121) unterstützen ihn nicht.- CSS Cascade Layers (
@layer): Breite Unterstützung seit 2022. Für ältere Browser kann ein PostCSS-Plugin Layers auflösen.
JavaScript-APIs in Can I Use prüfen
Can I Use beschränkt sich nicht auf CSS – auch JavaScript-Web-APIs werden abgedeckt. Besonders relevant 2026:
- Intersection Observer: Weitgehend universal unterstützt (alle modernen Browser). Für sehr alte iOS-Versionen gibt es ein offizielles Polyfill.
- WebP-Bildformat: Vollständige Unterstützung in allen aktuellen Browsern seit Safari 14 (2020). IE 11 unterstützt WebP nicht – da IE 11 Marktanteil unter 0,5 % liegt, ist ein Fallback 2026 kaum noch nötig.
- WebGPU: Noch in der Einführungsphase. Chrome (113+) und Edge unterstützen es. Firefox und Safari haben experimentelle Implementierungen. Für Produktivumgebungen 2026 noch nicht breit einsetzbar.
Polyfills und Fallbacks einsetzen
Wenn ein Feature nicht unterstützt wird, gibt es drei Strategien:
- Progressive Enhancement: Das Feature wird als Verbesserung obendrauf geladen, der Kern funktioniert ohne es. Beispiel:
@supportsin CSS nutzen, um moderne Layouts nur für unterstützende Browser zu aktivieren. - Polyfill: JavaScript-Code, der das fehlende Feature nachbaut. Polyfills gibt es für viele Web-APIs (IntersectionObserver, ResizeObserver, Fetch). Nachteil: zusätzlicher JavaScript-Overhead.
- Fallback-Werte: In CSS kann man Werte doppelt angeben – der ältere Wert steht zuerst und wird von modernen Browsern überschrieben. Beispiel:
display: flex; display: grid;
Browserslist für Build-Tools
Wer mit Bundlern wie Vite, webpack oder Parcel arbeitet und Babel oder PostCSS einsetzt, kann die Ziel-Browser über das Browserslist-Format definieren. Eine typische Konfiguration in package.json:
"browserslist": [
"> 0.5%",
"last 2 versions",
"not dead",
"not IE 11"
]Browserslist greift intern auf Can-I-Use-Daten zurück. PostCSS/Autoprefixer fügt dann automatisch die benötigten Vendor-Prefixe hinzu; Babel transpiliert nur die JavaScript-Syntax, die die Ziel-Browser nicht nativ unterstützen.
Can I Use vs. MDN-Kompatibilitätstabellen
Beide Tools sind exzellente Quellen, haben aber unterschiedliche Stärken. Can I Use bietet eine schnelle visuelle Übersicht und globale Nutzungsstatistiken. Die MDN Web Docs-Kompatibilitätstabellen sind tiefer und dokumentieren auch spezifische Sub-Features, Flaggen-Optionen und bekannte Bugs. Für den schnellen Check ist Can I Use ideal; für die detaillierte Feature-Recherche lohnt sich ein Blick auf MDN.
FAQ: Can I Use richtig nutzen
- Wie aktuell sind die Daten auf Can I Use?
- Die Daten werden regelmäßig aus mehreren Quellen aktualisiert, darunter der offizielle MDN Browser Compatibility Data (BCD) auf GitHub. Neue Browser-Versionen werden typischerweise innerhalb weniger Wochen nach Release eingetragen. Für tagesaktuelle Informationen lohnt sich ein Blick in die Release-Notes der jeweiligen Browser.
- Kann ich Can I Use offline verwenden?
- Ja. Das npm-Paket
caniuse-dbstellt die Rohdaten als JSON-Dateien bereit und wird von Browserslist genutzt. Mitnpx browserslist "last 2 Chrome versions"kann man offline abfragen, welche Browser-Versionen gemeint sind. - Was bedeutet „partial support" (gelbe Felder) konkret?
- Teilunterstützung bedeutet, dass das Feature implementiert ist, aber mit Einschränkungen – zum Beispiel fehlen bestimmte Sub-Properties, das Feature funktioniert nur mit einem Vendor-Prefix, oder es gibt bekannte Bugs in der Implementierung. Die genaue Einschränkung ist im Hinweistext unterhalb der Tabelle beschrieben.
- Wie integriere ich Can-I-Use-Daten in meinen Entwicklungs-Workflow?
- Der einfachste Weg ist die Browserslist-Konfiguration im Projekt. Für VS Code gibt es außerdem die Extension „Can I Use in VS Code", die direkt beim Tippen Kompatibilitätsinformationen einblendet. Alternativ kann man die Can-I-Use-API in eigene Tooling-Scripts integrieren.