Lesetipp: Ein „neues“ select-Element

[Matthias Scharwies]

Guten Morgen,

Das Web besteht fast nur aus Logins und Formularen - und deshalb bewegt sich auch etwas bei den Formular-Elementen.

Una Kravets stellt hier das „neue“ select-Element vor:

Request for developer feedback: customizable select

Warum in Anführungszeichen? Anders als bei popover gibt es keine neuen Elemente und Attribute (als Name war mal <selectlist> im Gespräch), sondern nur neue Selektoren, mit denen sich das bestehende HTML besser formatieren lässt.

Bis jetzt nur in Chrome Canary 130.

Ich bin gespannt!

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

The new customizable select comes with some default styles that look the same across browsers and operating systems.

Womit dann die Idee gestorben ist, dass man die Darstellung von Form Elementen dem Browser überlassen sollte, damit sie passend zum jeweiligen Gerät und in der Art des jeweiligen UI dargestellt werden.

Rolf

[Matthias Scharwies]

Servus!

Hallo Matthias,

The new customizable select comes with some default styles that look the same across browsers and operating systems.

Womit dann die Idee gestorben ist, dass man die Darstellung von Form Elementen dem Browser überlassen sollte, damit sie passend zum jeweiligen Gerät und in der Art des jeweiligen UI dargestellt werden.

Ja, wobei das eben seit der Einführung von CSS für (fast) alle Elemente außer <select> eh schon galt. Verweise kann man formatieren, wie man will. Bis auf diejenigen, die's übertreiben

a {
  text-decoration: none; 
  color: currentColor;
}

ist das doch kein Problem, oder?

Herzliche Grüße

Matthias Scharwies

[Matthias Scharwies]

Guten Morgen,

The new customizable select comes with some default styles that look the same across browsers and operating systems.

Womit dann die Idee gestorben ist, dass man die Darstellung von Form Elementen dem Browser überlassen sollte, damit sie passend zum jeweiligen Gerät und in der Art des jeweiligen UI dargestellt werden.

Die Diskussion hatten wir iirc 2014 schonmal als ich Ghost-Buttons stylen wollte und Matthias Apsel meinte, dass Buttons im Browser immer im Default gestylt werden sollten.

Bei select ist es doch so, dass es - eben wegen der mangelnden Gestaltungsmöglichkeiten - nicht mehr so oft verwendet wurde. „Profis“ bauen das mit divs und spans nach oder verwenden eine Combobox, Dropdown, Picker, etc.

Die open-ui.org hat hier eine Übersicht über die Varianten und will das eben wieder mit nativen Elementen realisieren und vereinheitlichen.

Herzliche Grüße

Matthias Scharwies

[Jörg]

Hallo,

Die Diskussion hatten wir iirc 2014 schonmal als ich Ghost-Buttons stylen wollte und Matthias Apsel meinte, dass Buttons im Browser immer im Default gestylt werden sollten.

Wer macht das denn heute noch so?
Mal ehrlich.
Selbst die Forenbuttons hier sind gestyled.
Und normale Checkboxen gehen ja so gerade noch, aber ungestylte Radio-Buttons sind nun wirklich nicht sehr hübsch, fast egal, in welcher Systemumgebung.

Jörg

[Felix Riesterer]

Lieber Matthias,

Request for developer feedback: customizable select

ist Dir auch aufgefallen, dass sie den Fall mit multiple so ganz und gänzlich vergessen haben? Jedenfalls findet man keinerlei Hinweise, wie das mit mehreren möglichen Auswahlen funktionieren soll.

<select>
  <button>
    <selectedoption></selectedoption>
  </button>
  // Everything else that will go into the ::picker(select) popover
</select>

Da sehe ich keinen Hinweis, wie das bei mehreren gewählten Optionen aussehen soll. Klar, man könnte mehrere <selectedoption>-Elemente in den Button hineindrücken. Aber wie soll der dann aussehen?

Für mich ist das ein unausgegorener Ansatz. Vielleicht wäre ein neues Element in der Tat die bessere Idee gewesen.

Liebe Grüße

Felix Riesterer

[Matthias Scharwies]

Servus!

Lieber Matthias,

Request for developer feedback: customizable select

ist Dir auch aufgefallen, dass sie den Fall mit multiple so ganz und gänzlich vergessen haben? Jedenfalls findet man keinerlei Hinweise, wie das mit mehreren möglichen Auswahlen funktionieren soll.

<select>
  <button>
    <selectedoption></selectedoption>
  </button>
  // Everything else that will go into the ::picker(select) popover
</select>

Da sehe ich keinen Hinweis, wie das bei mehreren gewählten Optionen aussehen soll. Klar, man könnte mehrere <selectedoption>-Elemente in den Button hineindrücken. Aber wie soll der dann aussehen?

Bei der open-ui.org habe ich Folgendes gefunden:

The HTML parser will not allow <button> or <datalist> children when the multiple or size attributes are present on <select>. This will ensure that the old rendering behavior of multiple and size is used.

Für mich ist das ein unausgegorener Ansatz. Vielleicht wäre ein neues Element in der Tat die bessere Idee gewesen.

Es ist halt viel im Fluß. Siehe popover und popovertarget, denen ein invoketarget für dialog entsprechen sollte. Das kommt jetzt als command und commandfor.

Aber es gibt ja auch einige CSS-Eigenschaften, die danach noch umbenannt / wieder abgeschafft wurden.

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Felix Riesterer,

ist Dir auch aufgefallen, dass sie den Fall mit multiple so ganz und gänzlich vergessen haben?

Nein, das haben sie nicht. Es steht auf der Todo-Liste.

Note: The multiple and size attributes on select (<select multiple> and <select size=n>) are not supported in appearance: base-select yet.

Ich finde aber ein paar andere Dinge merkwürdig:

selectedoption: "reflects the inner html of the selected option" - ja, das ergibt bei einer Multiselect-Liste keinen Sinn. Aber warum brauche ich ein Ende-Element? Wenn ich ein Ende-Element habe, heißt das dann, dass ich auch Inhalt reinschreiben kann? Was passiert damit? Das ist unausgegoren, eigentlich müsste selectedoption inhaltsleer sein und kein Ende-Tag brauchen, wie <img> oder <br>.

option::before: Wieso ::before? In Listen ist das ::marker, was ich hier für wesentlich angemessener halten würde.

Ich finde es auch nicht so toll, das valide Markup eines Elements vom CSS abhängig zu machen. Ohne :picker(select) sind in select ja nur optgroup, option und hr erlaubt, mit dem Picker kommt mehr dazu. Opt-in schön und gut, aber das Opt-In gehört ins Markup, nicht ins CSS.

Dann finde ich :picker(select) redundant. Selbst wenn es irgendwann noch weitere Picker gibt, wie :picker(date) oder :picker(color), so ergeben die doch nur Sinn im Kontext ihres Elements. Ein Date-Picker für ein Color-Input ist Blödsinn. Deshalb meine ich, dass :picker allein völlig ausreichen sollte.

Rolf

[Gunnar Bittersmann]

@@Felix Riesterer

ist Dir auch aufgefallen, dass sie den Fall mit multiple so ganz und gänzlich vergessen haben?

Besser ist auch. multiple kannste vergessen. Unbrauchbar. (Außer vielleicht für Spezialanwendungen, wo man die Nutzer schulen kann.)

Das hätte niemals Einzug in die HTML-Spec halten sollen und kann eigentlich weg.

Für Optionen mit Mehrfachauswahl sind Checkboxen da.

Kwakoni Yiquan

[Felix Riesterer]

Lieber Gunnar,

Für Optionen mit Mehrfachauswahl sind Checkboxen da.

da könnte ich nun dagegenhalten, dass für Einfachauswahl die Radio-Buttons da sind. Sowohl bei Checkboxen, als auch bei Radio-Buttons, braucht es jede Menge mehr an Markup (Label, passende name- und id-Attribute eventuell plus Blockelemente als Container), bei select dagegen nicht.

Liebe Grüße

Felix Riesterer

[Gunnar Bittersmann]

@@Felix Riesterer

Für Optionen mit Mehrfachauswahl sind Checkboxen da.

da könnte ich nun dagegenhalten, dass für Einfachauswahl die Radio-Buttons da sind.

Ja. Das gegenüber select vorzuziehende UI-Element.

Sowohl bei Checkboxen, als auch bei Radio-Buttons, braucht es jede Menge mehr an Markup (Label, passende name- und id-Attribute eventuell plus Blockelemente als Container), bei select dagegen nicht.

Wenn das irgendein Problem sein sollte, dann ist es eins des Entwicklers, das er nicht auf die Nutzer abwälzen sollte.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

ich denke, das Abgrenzungskriterium Radioliste vs Select ist die Anzahl der Optionen.

Select ist kompakt und den meisten Usern bekannt. Kein Grund, es zu verteufeln.

Rolf

[Gunnar Bittersmann]

@@Rolf B

ich denke, das Abgrenzungskriterium Radioliste vs Select ist die Anzahl der Optionen.

Ich denke, da denkst du falsch.

Select ist kompakt

Wenn das das Kriterium ist, hieße das ja: bei wenigen Optionen spart man mit select gegenüber einer Radiobuttongruppe nicht allzu viel, also wäre select bevorzugt bei vielen Optionen anzuwenden.

Ich denke, gerade bei vielen Optionen sollte man besser Radiobuttons verwenden, nicht select.

Und was soll das Gerede mit „kompakt“ überhaupt? Auf Webseiten hat man – im Gegensatz zu anderen Medien – allen Platz der Welt. Kein Grund, an der falschen Stelle Platz sparen und besonders kompakt sein zu wollen.

und den meisten Usern bekannt. Kein Grund, es zu verteufeln.

Das hat auch niemand getan. Ich sagte „das vorzuziehende UI-Element“, nicht „das unbedingt zu verwendende UI-Element“.

Kwakoni Yiquan

[Rolf B]

Hallo Gunnar,

Wenn das das Kriterium ist, hieße das ja: bei wenigen Optionen spart man mit select gegenüber einer Radiobuttongruppe nicht allzu viel, also wäre select bevorzugt bei vielen Optionen anzuwenden

Yup, genauso sehe ich das. Wenn ich aus 3 Optionen auswählen kann, geht eine Radioliste. Bei 30 Optionen ist das quälend.

Der behauptete unendliche Platz geht auf Kosten der Übersichtlichkeit. Ich scrolle mich zu Tode, um durch's Formular zu kommen. Moderne Webseiten mit riesigen Bildern, breiten Werbebannern und viel Weißraum verschärfen das noch.

Es liegt vermutlich daran, dass ich in den 80er Jahren digitalisiert wurde, wo 640×480 Dialoge üblich waren (und leider von Microsoft heute immer noch generiert werden), dass mir heutige Webformulare gruselig vorkommen.

Rolf

[Rolf B]

Hallo Gunnar,

als weiteres Entscheidungskriterium kann man den Umfang der Optionen verwenden. Besteht die Option aus einem Wort, das selbsterklärend ist (z.B. Farbe (bei fester Palette, sonst input type="color")), ist eine Radioliste blöd und ich würde einen select vorziehen. Braucht jede Option einen Erklärtext, ist sie optimal. Dazwischen liegt ein Gradient von Graustufen…

Rolf

[Felix Riesterer]

Lieber Gunnar,

Sowohl bei Checkboxen, als auch bei Radio-Buttons, braucht es jede Menge mehr an Markup (Label, passende name- und id-Attribute eventuell plus Blockelemente als Container), bei select dagegen nicht.

Wenn das irgendein Problem sein sollte, dann ist es eins des Entwicklers, das er nicht auf die Nutzer abwälzen sollte.

wenn man sich anschaut, warum dieser Krampf mit dem „neuen“ select gemacht wird, nämlich die größtmögliche visuelle Gestaltungsfreiheit zu haben, ist das Mehr an Markup für Radiobuttons (single select) oder Checkboxen (multiple select) ein Vorteil und kein Nachteil. Denn ehe ich einen solchen Quatsch an Markup baue, wie ihn die Proponenten vorschlagen, kann ich gleich auf bereits Vorhandenes zurückgreifen, für das ich keinen nightly build eines speziellen Browsers benötige. Zugänglichkeit inklusive.

Liebe Grüße

Felix Riesterer

[Matthias Scharwies]

Liebe SELFer,

manchmal erkenne ich bei Euch eine Lust am Streiten, die mir Angst macht.

Quatsch [...] baue, [...], für das ich keinen nightly build eines speziellen Browsers benötige. Zugänglichkeit inklusive.

Der nightly build ist doch die akzeptierte Vorgehensweise, Neues zu testen, irgendwann kommt es ohne flag in einen Browser, dann findet man das Feature in Caniuse und wenn es dann in einem der Konkurrenzbrowser landet, wird der entsprechende Wiki-Artikel geändert.

Dort können dann auch Anwendungsfälle oder eben auch Empfehlungen, wie man es sonst realisieren könnte, besprochen werden.

Denn ehe ich einen solchen Quatsch [...] baue, [...] kann ich gleich auf bereits Vorhandenes zurückgreifen, ...

Ja, und das ist doch das Tolle am vorgeschlagenen Weg:

Don't break the web! - keine neuen Elemente, unser Wiki-Beispiel funktioniert auch in Zukunft, auch wenn die Jüngeren außer Michael Jackson wohl niemand mehr kennen:

    <select name="top5" size="5">
      <option>Heino</option>
      <option>Michael Jackson</option>
      ...
    </select>

Was mir auffällt:

Das Dropdown-Menü

1. übernimmt die gewählte option ohne weiteres Zutun als Inhalt, 👍
2. nimmt meine CSS-Formatierung nicht. 😟

Eine Gestaltung mit CSS, ein anderer Option-Inhalt als plain text ist nicht gewollt; die Krücke mit Emojis funktioniert im Firefox, bei dem Mexiko-Emoji aber nicht in Chrome und Edge. 😟

Eine Angabe/Hilfestellung wurde früher so realisiert:

		<select id="age" name="age">
			<option value="">bitte wählen</option>
			<option value="10">bis 10 Jahre alt</option>
			<option value="20">bis 20 Jahre alt</option>
			...
		</select>

Da wird künftig das Konstrukt vorgeschlagen:

<select>
  <button>
      <selectedoption></selectedoption>
  </button>
  <option value="reply">Reply</option>
   ...
</select>

Das kann man machen, wenn man die Angabe speziell gestalten will,
aber man kann es auch weglassen.

Und natürlich kann man weiterhin Checkboxen oder Radio-Buttons - aber eben leider auch <div>s und <span>s verwenden.

---

Ich habe den Lesetipp gepostet, weil SELFHTML neue Entwicklungen verfolgt. Das Feature ist hinter einem flag versteckt - kann sich also noch ändern.

Sobald die Browserunterstützung da ist, wird es im Wiki beschrieben. ^[1]

Herzliche Grüße

Matthias Scharwies

---

1. Das Wiki sollte nicht den Stand von 2004, „als das Web noch gut war“ konservieren, sondern neue Entwicklungen neutral und nicht wertend beschreiben.
   Empfehlungen, es besser so oder so zu gestalten, gehören natürlich dazu.
   Und dann können die Leser entscheiden, ob sie es einsetzen wollen. ↩︎

[Auge]

Hallo

Don't break the web! - keine neuen Elemente, unser Wiki-Beispiel funktioniert auch in Zukunft, auch wenn die Jüngeren außer Michael Jackson wohl niemand mehr kennen:

    <select name="top5" size="5">
      <option>Heino</option>
      <option>Michael Jackson</option>
      ...
    </select>

Och, hat Heino nicht gerade mit seinem Bericht über seinen USA-Besuch inklusive impliziter Wahlempfehlung für Deutschland Schlagzeilen gemacht? Selbst von denen, die ihn nicht mehr als Musiker erlebt haben, werden ihn jetzt wohl viele kennengelernt haben. Und selbst die anderen drei Optionen sind mMn auch heute nicht ganz unbekannt (und nicht nur bei alten SäckInnen).

Tschö, Auge

[Rolf B]

Hallo Auge,

ich bin älter und muss zu meiner Schande gestehen, dass ich von Tom Waits noch nie was gehört habe 😲. Von den übrigen schon…

Rolf

[Auge]

Hallo

ich bin älter …

Als ich oder als „alte SäckInnen“? 😆

… und muss zu meiner Schande gestehen, dass ich von Tom Waits noch nie was gehört habe 😲.

Ach herrje. Ich bin ja nun beileibe kein Fan seiner Musik, aber seine Songs liefen und laufen zumindest immer wieder mal im Radio, wenn schon nicht auf dem heimischen Plattenteller, Irgendeine-Disk-Player, Streaminggerät. Ich kann mir garnicht vorstellen, wie man da so gänzlich „vorbei gegangen“ sein kann.

Tschö, Auge

[Gunnar Bittersmann]

@@Rolf B

ich bin älter und muss zu meiner Schande gestehen, dass ich von Tom Waits noch nie was gehört habe 😲.

Dann wird’s aber Zeit.

Und hier die Bösendorfer-Version für @at.

Kwakoni Yiquan

[Gunnar Bittersmann]

@@Rolf B

ich bin älter und muss zu meiner Schande gestehen, dass ich von Tom Waits noch nie was gehört habe 😲.

Du hast nicht Bruce Springsteen & The E Street Band Live/1975–85 im Plattenschrank? Oder nicht zuende gehört? Das hört mit einem Cover von Tom Waits’ „Jersey Girl“ auf.

Hier im Original und hier beide im Duett.

Kwakoni Yiquan

PS: Gundermann hat sich für „Wo bleiben wir“ der Musik von Tom Waits’ „Downtown Train“ bedient.

[Rolf B]

Hallo Gunnar,

Plattenschrank

Ich bin vermutlich ein Alien. So etwas besitze ich nicht. Weder Schrank noch entsprechenden Inhalt noch entsprechende Wiedergabegeräte. Mein Musikkonsum beschränkt sich auf Radiohören beim Autofahren. Oder auf's Anschauen von SNW S2-E9… Oder auf's gelegentliche Youtube-Musikvideo-Surfen.

Rolf

[Gunnar Bittersmann]

@@Rolf B

Oder auf's Anschauen von SNW S2-E9…

Gibt’s auch ohne die störenden Szenen dazwischen. 😆

Kwakoni Yiquan

[Matthias Scharwies]

Servus!

Lea Verou schrieb:

So it turns out you can use writing-mode in Chrome & Firefox to lay out a <select> horizontally 🙃

https://codepen.io/leaverou/pen/PoMzXXx

Herzliche Grüße

Matthias Scharwies

[Rolf B]

Hallo Matthias,

nicht in meinem Chrome. Brauche ich dafür die gelbe Version (Canary)? Lea sagt nichts darüber.

Im Firefox geht's, für einen bestimmten Wert von „geht“:

Rolf

[Matthias Scharwies]

Guten Morgen,

How should <selectedoption> work? von Jake Archibald, 18.10.2024

We're finally getting a way to fully style & customise <select> elements! But there's a detail I'd like everyone's opinion on.

<selectedoption> automatically displays the currently selected <option> within the <button> that opens the popover menu.

It's entirely optional, so if you wanted to manually update the content of the <button> when the selected <option> changes, you can, and you get a lot more control that way. But <selectedoption> is much easier, and works without JavaScript.

When the selected <option> changes, it clears the contents of the <selectedoption>, takes a clone of the contents of the newly selected <option>, and inserts it into the <selectedoption>.

This is kinda new and weird behaviour.

Bitte lest den ganzen Artikel - er findet's dann doch nicht so shclimm!

Herzliche Grüße

Matthias Scharwies

[Felix Riesterer]

Lieber Matthias,

es wird immer merkwürdiger und noch weniger intuitiv.

1. Ein Element wird ohne Deine Kontrolle inhaltlich(!) verändert, weil ein Mechanismus an anderer Stelle dort einen Zustand ändert.
2. Er sagt selber: But, I can't think of a better way to do this, um nach drei Bedingungen mit dem Unterkapitel But there are limitations fortzufahren. Soll uns das von der Richtigkeit des gewählten Ansatzes überzeugen? Also mich überzeugt das nicht.

Wir erinnern uns: Erlaubte Kindelemente von <select> sind bisher <option> und <optgroup> - sonst nichts. Eine Abwärtskompatibilität sollte das besser berücksichtigen, als da noch einen (wirklich nur einen?) <button> mit integriertem <selectedoption> oder noch viel mehr beliebigen Kram vorzusehen.

Das bedeutet also, dass es mit der für HTML immer strengstens gebotenen Abwärtskompatibilität hier nur zum Teil klappt. Würde denn das neue <selectoption> automatisch ins DOM injiziert, wenn das ursprüngliche HTML-Dokument dieses nicht definiert? Und weil das neue <select> außerdem einen Button um dieses Element braucht, ohne den es auch nicht automagisch injiziert werden kann, müsste ein älteres Dokument zumindest diesen enthalten, damit man rein mit CSS dieses Selection-Dingsbums auch wirklich visuell aufhübschen kann. Aber der war nach der bisherigen Spec immer ungültiges HTML! Oder soll Abwärtskompatibilität nur bedeuten, dass es wie früher funktioniert und auch wie früher aussieht, wenn ausschließlich die altbekannten Kindelemente darin enthalten sind? Setzt man also bewusst auf Tag-Soup als Konzept?

Und genau jetzt stellt sich mir die Frage, ob man diese Altlast nicht lieber in der Ecke weiter verschimmeln lassen sollte, um für modernere Ansätze gleich ein neues Element samt allen Zutaten zu entwerfen. Das könnte man dann gleich mit allen Schikanen und style-baren Bausteinen entwerfen. Wäre doch voll super! Oder... ach so, jetzt will jeder, dass das Ding in seiner Struktur grundsätzlich frei und flexibel sein soll, weil jeder so seinen eigenen use case dafür hat. Hmm. Dann nehme man halt das, was es ohnehin schon längst gibt und höre damit auf, Zeit und Energie in eine nur homöopathisch sinnvolle Verschlimmbesserung zu stecken!

Liebe Grüße

Felix Riesterer