Lesetipp: Ein „neues“ select-Element
Matthias Scharwies
- formulare
- html
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
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
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
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
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
Lieber Matthias,
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
Servus!
Lieber Matthias,
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
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
@@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
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
@@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
- undid
-Attribute eventuell plus Blockelemente als Container), beiselect
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
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
@@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
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
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
Lieber Gunnar,
Sowohl bei Checkboxen, als auch bei Radio-Buttons, braucht es jede Menge mehr an Markup (Label, passende
name
- undid
-Attribute eventuell plus Blockelemente als Container), beiselect
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
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ü
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
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. ↩︎
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
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
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
@@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
@@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.
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
@@Rolf B
Oder auf's Anschauen von SNW S2-E9…
Gibt’s auch ohne die störenden Szenen dazwischen. 😆
Kwakoni Yiquan
Servus!
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