`<select>` jetzt per CSS anpassbar

• Ab Chrome 135 wird für das <select>-Element eine neue Funktion unterstützt, die CSS-Anpassungen ermöglicht und dabei die Barrierefreiheitsstandards beibehält
• Nach jahrelanger Abstimmung an der Spezifikation und Entwicklung wird dies als robuste Komponente bereitgestellt, die auch in älteren Browsern nicht kaputtgeht
• Auch HTML-Inhalte können eingebunden werden, und mit appearance: base-select sind Animationen, Styling und vielfältige Anpassungen möglich

Einführung in appearance: base-select

• Die neue CSS-Eigenschaft appearance: base-select versetzt <select>-Elemente in einen neuen anpassbaren Zustand

  .custom-select {  
    &, &::picker(select) {  
      appearance: base-select;    
    }  
  }  
  

• Neue Funktionen bei Verwendung von base-select

  • Geändertes Verhalten des HTML-Parsers des Browsers für Inhalte innerhalb von <select>
  • Änderungen an Rendering-Verhalten und interner Struktur
  • Neue interne Parts und States
  • Minimales Standarddesign (für Anpassungen optimiert)
  • Die angezeigten Optionen erscheinen wie ein Popover in der obersten Ebene
  • Die Position der Optionen lässt sich mit anchor() steuern

• Funktionen, die bei Verwendung von base-select entfallen

  • Kein Rendering von <select> außerhalb des Browserfensters
  • Keine Aufrufung der nativen Auswahl-UI des mobilen Betriebssystems
  • Die Breite der längsten <option> wird nicht berücksichtigt

HTML-Inhalte in <select> möglich

• Bisher ignorierten Browser Bilder oder SVGs innerhalb von <option>
• Mit appearance: base-select werden sie als HTML unverändert gerendert
• In Chrome sind Optionen mit eingebettetem SVG sichtbar, Safari, Firefox und andere unterstützen das jedoch nicht
• CodePen-Demo: Praxislink
• Diese Funktion wird als Finch-Experiment eingeführt und kann bei Bedarf wieder deaktiviert werden

Vollständige Anpassbarkeit

• Alle Bestandteile von base-select lassen sich ersetzen, animieren und stylen
• Damit lassen sich aussagekräftige Auswahl-UIs in unterschiedlichen Designs erstellen
• Beispiele sind Statusanzeigen, Optionen mit Avataren, Farbwähler oder die Auswahl eines Veröffentlichungsstatus
• CodePen-Demo: Praxislink

JavaScript-Schnittstelle unverändert

• Das bisherige JavaScript-Verhalten von <select> bleibt unverändert erhalten
• Wenn jedoch HTML in <option> eingefügt wurde, sollte getestet werden, da sich das Parsing des ausgewählten Werts geändert hat
• Wird das Attribut value verwendet, sind keine zusätzlichen Anpassungen nötig

Weiterführende Materialien

Webstandards

• Open UI Select-Spezifikation
• HTML-Spezifikation Pull Request
• Chrome Intent to Ship

Materialien zu Chrome

• Chrome-Blogbeitrag mit Anfrage und Erklärung
• Ergebnisse des Community-Feedbacks
• <select> mit <hr> verwenden
• Erläuterung von Una / Link zur Zusammenfassung der Änderungen
• Unas CodePen-Sammlung

Community-Materialien

• CodePen-Sammlung von Brecht De Ruyte
• Vergleich von nativen vs. benutzerdefinierten Selects bei CSS Tricks
• <select>-Implementierung von Open Props UI
• Beispiel für einen animierten benutzerdefinierten Select

Demos mit angepassten <select>-Elementen

• Demo von Una
• Demo von Brecht
• Demo von Adam

[GN⁺]

Hacker-News-Kommentare

• Dass ich über diese Funktion unverhältnismäßig begeistert bin, verrät wahrscheinlich den Webentwickler in mir aus den frühen 2000ern. Das ist eine sehr nützliche Funktion, weil das select-Element Fähigkeiten bietet, die sich in HTML nicht nachbilden lassen

  • Als Nächstes müssen nun Autovervollständigung und Tag-Picker hinzukommen

• Bis diese Funktion breit unterstützt wird, sollte man sie als progressive Verbesserung einsetzen. Laut caniuse.com wird sie derzeit weltweit zu 46 % unterstützt

  • Man muss darauf achten, Nutzern mit nicht unterstützten Browsern keine schlechte Erfahrung zu bieten
  • Es ist wichtig, keine entscheidenden Informationen oder Funktionen in das neue Styling zu packen

• Ich freue mich sehr, dass das umgesetzt wird. Es wird eine deutlich größere Verbesserung sein als benutzerdefinierte Ersatzlösungen für Auswahlfelder

• Mich beunruhigt, dass dadurch keine integrierten mobilen Betriebssystem-Komponenten ausgelöst werden. Die integrierten Komponenten sind zuverlässig, barrierefrei und reaktionsschnell

  • Es ist gut, sich darauf verlassen zu können, dass die Android-Oberfläche aufgeht. Das gilt nicht nur für Auswahlfelder, sondern auch für Datums-/Zeiteingaben

• Bei manchen Controls ist es besser, kein Styling anzuwenden. Bei Scrollbars sind sie oft zu schmal oder der Farbkontrast ist zu schlecht, sodass sie schwer zu benutzen sind

  • Das Standard-select-Element ist nicht das schönste Control, erfüllt aber seinen Zweck

• Darauf scheinen Webentwickler seit Jahrzehnten zu warten. Es hat das Potenzial, viele JS-Bibliotheken zu ersetzen

  • Ich habe Chrome nicht installiert, frage mich aber, wie im Beispielvideo mit Mehrfachauswahlfeldern umgegangen wird

• select-Elemente lassen sich in Chromium-Browsern nun mit CSS anpassen

  • Webstandards werden immer komplexer

• Ein Link zum Firefox-Issue wurde bereitgestellt

• Wenn das so weitergeht, werden wir bald Funktionsparität mit VB6 haben

• Besser als kaputte JS-Bibliotheken. Aber meine Hauptsorge ist, wie das Layout bei vielen Optionen aussieht

  • Dass dadurch keine integrierten mobilen Betriebssystem-Komponenten ausgelöst werden, ist beängstigend. Ich frage mich, wie das Layout dann aussieht
  • Die angezeigten Optionen werden mit anchor() positioniert
  • Das ist experimentell, aber vielleicht ist genau dieser Teil der beste daran. Wenn das in CSS wirklich funktioniert, wäre das erstaunlich

[carnoxen]

Heißt das, dass <selectlist> dann nicht mehr nötig sein wird?

[deminoth]

Eine andere Sache: Im Slack-Bot wird das <select> im Titel offenbar nicht angezeigt, haha.

[xguru]

Ach, das werde ich später korrigieren.