Du baust für einen Kunden ein Buchungsformular. Alles sitzt – bis auf die Auswahlfelder. Das native <select> sieht in Chrome anders aus als in Safari, auf dem iPhone klappt ein grauer Systemzylinder hoch, und in das Design deines Kunden passt davon nichts. Also greifst du zu einer JavaScript-Bibliothek wie Choices.js oder Select2, baust das Dropdown mit <div>-Elementen nach – und handelst dir damit zusätzliche Kilobyte, eine weitere Abhängigkeit und ein Barrierefreiheits-Risiko ein, das du bei jedem Audit neu prüfen musst.
Genau dieser Kompromiss ist 2026 nicht mehr nötig. Der Browser kann das select-Element jetzt selbst gestalten – inklusive der aufklappenden Optionsliste, die früher für CSS tabu war. Dieser Beitrag zeigt dir, wie das funktioniert, wie weit der Browser-Support wirklich ist und warum sich der Umstieg gerade für kleine Agenturen lohnt.
select-Element mit CSS stylen: was sich 2026 ändert
Jahrelang war das <select> eine Blackbox. Du konntest den zugeklappten Button halbwegs gestalten, aber die eigentliche Optionsliste rendert das Betriebssystem – nicht der Browser. Deshalb ließ sich das Dropdown weder mit CSS stylen noch animieren, und deshalb gibt es überhaupt die ganzen JavaScript-Bibliotheken: Sie werfen das native Element weg und bauen aus <div>- und <li>-Elementen eine Attrappe, die man frei gestalten kann. Der Preis dafür ist hoch, denn Tastaturbedienung, Screenreader-Verhalten und die native Mobil-Darstellung müssen mühsam nachprogrammiert werden – und scheitern oft.
Der neue Ansatz dreht das um. Mit dem CSS-Wert appearance: base-select meldest du dich für ein gestaltbares select an. Der Browser behält das echte Formularelement mit all seiner eingebauten Logik, verändert aber sein Innenleben so, dass du jeden Teil davon mit CSS ansprechen kannst. Die aufklappende Liste landet dabei in der obersten Ebene der Seite, dem Top Layer, und wird über dieselbe Anker-Technik positioniert, die auch hinter der Popover API und dem CSS Anchor Positioning steckt. Das Ergebnis: ein natives select, das aussieht, wie dein Designer es will – ohne eine einzige Zeile Framework-Code.
appearance: base-select – so funktioniert der Schalter
Der Einstieg ist bewusst zweistufig. Du setzt appearance: base-select sowohl auf das <select> selbst als auch auf das zugehörige Picker-Element, das die Optionsliste darstellt:
select,
::picker(select) {
appearance: base-select;
}
Erst damit verlässt das Element den klassischen Modus und gibt seine Innenteile für CSS frei. Ab dann gestaltest du sie wie normale HTML-Bausteine. Über ::picker(select) stylst du die aufklappende Liste, über ::picker-icon den Pfeil, über ::checkmark das Häkchen der gewählten Option, und mit der Pseudoklasse :open reagierst du auf den aufgeklappten Zustand:
::picker(select) {
border: 1px solid #d0d0d0;
border-radius: 12px;
box-shadow: 0 8px 24px rgb(0 0 0 / 0.12);
}
select:open::picker-icon {
rotate: 180deg;
}
Der vielleicht größte praktische Gewinn: In die <option>-Elemente darf jetzt echtes HTML. Du kannst also eine Länderauswahl mit kleinen Flaggen bauen, eine Produktvariante mit Vorschaubild oder einen Status-Filter mit farbigem Punkt davor – alles Dinge, für die du früher zwingend eine Bibliothek gebraucht hast.
Was du jetzt gestalten kannst
Anders als beim alten select ist bei einem base-select praktisch jeder Teil erreichbar: der Auslöser-Button mit der aktuell gewählten Anzeige, die Optionsliste als Ganzes, jede einzelne Option samt Hover- und Auswahl-Zustand, das Markierungshäkchen und das Pfeil-Icon. Du kannst Abstände, Farben, Schriften, Ränder und sogar Ein- und Ausblend-Animationen definieren. Für den Agentur-Alltag heißt das: Das Auswahlfeld fügt sich endlich nahtlos ins Corporate Design des Kunden ein, statt als Fremdkörper aufzufallen.
Ein Beispiel aus der Praxis
Stell dir die Versandauswahl im Checkout eines Kunden vor. Bisher stand dort schlicht „DHL", „DPD" oder „Abholung" als grauer Systemtext. Mit einem gestaltbaren select legst du vor jede Option das passende Logo und darunter die Lieferzeit – in ganz normalem HTML innerhalb des <option>:
<select>
<option value="dhl">
<span class="logo">🚚</span>
<span class="label">DHL · 1–2 Tage</span>
</option>
<option value="abholung">
<span class="logo">🏬</span>
<span class="label">Abholung · heute</span>
</option>
</select>
Früher war das nur mit einer Bibliothek und einem Haufen <div>-Markup möglich, das du anschließend wieder für die Tastatur zugänglich machen musstest. Jetzt bleibt es ein einziges, natives Formularfeld – und sendet beim Absenden ganz normal seinen value mit, ohne dass du am Formular-Handling etwas ändern musst.
Browser-Support 2026: endlich breit genug
Die entscheidende Frage für die Praxis ist natürlich: Kann ich das heute in einem Kundenprojekt einsetzen? Die Antwort ist 2026 erstmals ein belastbares Ja. Google hat das gestaltbare select mit Chrome 135 im März 2025 ausgeliefert, womit auch das Chromium-basierte Edge die Funktion beherrscht. Apple ist mit Safari 27 Mitte 2026 nachgezogen. Und Firefox hat die Unterstützung ebenfalls umgesetzt – mit Version 149 ist appearance: base-select an Bord, dort allerdings noch hinter einem Konfigurations-Flag und damit nicht standardmäßig für alle Nutzer aktiv.
Unterm Strich: Die große Mehrheit deiner Besucher – alle auf Chrome, Edge und aktuellem Safari – bekommt die gestaltete Variante. Das war der fehlende Baustein, der den produktiven Einsatz bisher blockiert hat. Welche neuen Web-Funktionen browserübergreifend als sicher gelten, lässt sich übrigens jederzeit über den Baseline-Status nachschlagen, statt für jedes Feature einzeln die Kompatibilitätstabellen zu durchforsten.
Progressive Enhancement statt Alles-oder-nichts
Das Schöne an appearance: base-select ist, dass du nicht auf hundertprozentige Abdeckung warten musst. Das Verfahren ist ein Opt-in und fällt sauber zurück: Ein Browser, der den Wert nicht kennt, ignoriert ihn und zeigt das ganz normale, voll funktionsfähige select. Niemand bekommt ein kaputtes Formular – im schlechtesten Fall eben das Standard-Dropdown des Systems.
Damit auch deine aufwendigeren CSS-Regeln nur dort greifen, wo sie verstanden werden, kapselst du sie in eine Feature-Abfrage:
@supports (appearance: base-select) {
/* Nur hier die gestaltete Variante aufbauen */
}
So baust du die schicke Version als Erweiterung obendrauf, während die solide native Basis für jeden funktioniert. Genau das ist der Kern von Progressive Enhancement – und der Grund, warum du die Technik ohne Risiko schon in das nächste Kundenprojekt einbauen kannst.
Was das für dein Kundenprojekt bedeutet
Der offensichtlichste Gewinn ist weniger Ballast. Eine typische Dropdown-Bibliothek wiegt mitsamt ihren Abhängigkeiten schnell mehrere Dutzend Kilobyte. Fällt sie weg, wird die Seite schneller und du hast ein Paket weniger, das regelmäßig Update-Meldungen und Sicherheitswarnungen produziert. Dieser Aufräum-Effekt zahlt direkt auf die Ladezeit ein – ein Hebel, der beim Reduzieren fremder Skripte ohnehin eine zentrale Rolle spielt.
Mindestens genauso wichtig ist die Barrierefreiheit. Ein natives select bringt Tastaturbedienung, Fokus-Handling und Screenreader-Unterstützung von Haus aus mit. Nachgebaute Dropdowns aus <div>-Elementen verlieren genau das gern – und werden so zur Stolperfalle, die im schlimmsten Fall das Barrierefreiheitsstärkungsgesetz verletzt. Weil base-select das echte Formularelement erhält, bleibt diese eingebaute Zugänglichkeit bestehen. Du bekommst das gute Aussehen, ohne die Zugänglichkeit zu opfern – ein Kompromiss, den die alten Bibliotheken nie sauber hinbekommen haben.
Dazu kommt der Wartungsvorteil. Keine externe Komponente heißt: kein Versions-Upgrade, das irgendwann dein Build bricht, keine aufgegebene Bibliothek, die du in zwei Jahren mühsam ersetzen musst. Standard-HTML und -CSS altern deutlich langsamer als ein npm-Paket.
Eine Einschränkung gehört zur Ehrlichkeit dazu: Gerade weil du jetzt alles gestalten darfst, solltest du es nicht übertreiben. Ein Auswahlfeld muss als solches erkennbar bleiben – mit sichtbarem Pfeil, klarem Fokuszustand und ausreichend Kontrast. Die neue Freiheit ist eine Einladung, das native Element elegant einzukleiden, keine Lizenz, es bis zur Unkenntlichkeit umzubauen.
Fazit
Das select-Element mit CSS zu stylen war über ein Jahrzehnt lang der Grund, warum Agenturen zu JavaScript-Dropdowns gegriffen haben. Mit appearance: base-select ist dieser Grund 2026 entfallen: Chrome, Edge und Safari 27 unterstützen die Technik, Firefox hat sie implementiert, und weil sie als Opt-in sauber zurückfällt, kannst du sie risikofrei als Progressive Enhancement einsetzen. Für dich bedeutet das schlankere, schnellere und barrierefreie Formulare – ohne externe Bibliothek, ohne Wartungslast. Beim nächsten Kundenformular lohnt es sich, zuerst zu prüfen, ob ein native gestyltes select reicht, bevor du überhaupt eine Bibliothek ins Projekt holst.
- Mit appearance: base-select kann der Browser 2026 das komplette select-Element inklusive aufklappender Optionsliste nativ per CSS gestalten – ohne JavaScript-Bibliothek.
- Der Support ist breit genug für die Praxis: Chrome und Edge seit Chrome 135 (März 2025), Safari seit Version 27 (Mitte 2026), Firefox ab Version 149 (noch hinter einem Flag).
- Das Verfahren ist ein Opt-in und fällt sauber auf das native select zurück – per @supports als Progressive Enhancement risikofrei im Kundenprojekt einsetzbar.
- Weil das echte Formularelement erhalten bleibt, bleibt auch die eingebaute Barrierefreiheit (Tastatur, Screenreader) bestehen – anders als bei nachgebauten div-Dropdowns.
- Der Verzicht auf Dropdown-Bibliotheken spart Kilobyte, Update-Aufwand und Sicherheitsrisiken.