Es gibt einen Pseudo-Klassen-Selektor, :indeterminate, dessen Aufgabe es ist, Radio-Button-Inputs auszuwählen, die weder ausgewählt (haben das Attribut „checked“) noch abgewählt (haben dieses nicht) sind. Dies ist ein CSS3-Selektor, der möglicherweise eine Reaktion auf die HTML5-Spezifikation ist, die explizit erlaubt, dass Radio-Buttons in diesem Zustand sind.
Wenn keiner der Radio-Buttons in einer Radio-Button-Gruppe beim Einfügen in das Dokument ausgewählt ist, dann sind sie im Interface zunächst alle abgewählt, bis zu dem Zeitpunkt, an dem einer von ihnen ausgewählt wird (entweder durch den Benutzer oder durch Skript).
Was ist der Sinn von all dem? Nun... warum eine solch schlechte Benutzeroberfläche explizit zulassen?
Keine Wahl ausgewählt
In einem Kommentar hier letzte Woche hat Lee Kowalkowski es schön zusammengefasst:
Meiner Meinung nach ist das eine schlechte Benutzeroberfläche. Die beliebteste Option sollte ausgewählt sein. Wenn die Wahl von nichts gültig ist, dann ist eine Radio-Gruppe nicht gut geeignet, da der Benutzer die Gruppe nicht einfach in ihren unbestimmten Zustand zurückversetzen kann.
Es ist wiederholenswert: Der Benutzer kann die Gruppe nicht einfach in ihren unbestimmten Zustand zurückversetzen.
Die HTML4-Spezifikation machte mehr Sinn.
Zu jeder Zeit ist genau einer der Radio-Buttons in einer Gruppe ausgewählt. Wenn keiner der <INPUT>-Elemente einer Gruppe von Radio-Buttons „CHECKED“ angibt, dann muss der User-Agent zunächst den ersten Radio-Button der Gruppe auswählen.
Da das Verhalten der User-Agents variiert, sollten Autoren sicherstellen, dass in jeder Gruppe von Radio-Buttons einer zunächst „an“ ist.
Dieser zweite Teil dort, in einfacher Sprache: Da wir wissen, dass kein Browser dies tatsächlich befolgt, fügen wir diese spezielle Anmerkung hinzu, um Autoren daran zu erinnern, dies selbst in die Hand zu nehmen.
Meiner Meinung nach sollten wir zur HTML4-Spezifikation zurückkehren, aber die Browser sollten sie tatsächlich respektieren, indem sie jederzeit mindestens einen Radio-Button pro Gruppe erzwingen. Das würde dann den :indeterminate-Pseudo-Selektor irgendwie nutzlos machen.
Denken Sie daran, dass Radio-Buttons und Dropdown-Listen im Wesentlichen dasselbe sind (man kann nur eine von mehreren Optionen auswählen). Wenn Sie also einen „nicht ausgewählten“ Zustand benötigen, wäre vielleicht eine <select>-Liste mit einer Standardoption „Wählen“ die Lösung für Sie.
... oder „UNSPEZIFIZIERT“
„Wenn Sie einen „nicht ausgewählten“ Zustand benötigen, wäre vielleicht eine <select>-Liste mit einer Standardoption „Wählen“ die Lösung für Sie.“
Meiner Meinung nach wäre das auch ein schlechter Ansatz – es ist kein Gleichgestellter der anderen Elemente in der Gruppe (es ist eine Anweisung, ein „Meta“-Teil des Formulars, kein Wert – Sie haben kein Geschlecht von „Wählen“ und leben nicht im Zustand von „Wählen“). Wenn es als Radio-Button falsch aussehen würde (was „Wählen“ sicherlich tun würde), ist es auch als Select-Option falsch.
Eine Option wie „Keine“, „Unbekannt“ oder Ähnliches wäre die standardmäßige, konsistente Lösung.
Sicher, das Wort, das Sie wählen, ist diskutabel, aber zumindest können Sie die Dropdown-Liste zurück in den Zustand versetzen, in dem nichts ausgewählt ist. Oder genauer gesagt, es ist eine Option ausgewählt, aber bei der Verarbeitung würden Sie sie als keine Option behandeln.
Ich stimme der Hauptaussage auf jeden Fall zu, dass ein unbestimmter Radio-Button ein kaputter Radio-Button ist und eine Spezifikation, die ihn zulässt, ebenfalls kaputt ist. Anstatt den unbestimmten Zustand wieder wählbar zu machen, sollte er nie auftreten. Wenn „unbestimmt“ ein Zustand ist, sollte er deterministisch sein :)
Oder eine Checkbox mit JavaScript (liest jQuery), um sicherzustellen, dass nur eine Checkbox ausgewählt ist.
Checkboxen*
Ich stimme nicht zu. Checkboxen sind nicht dafür gemacht, Radios zu ersetzen... meiner Meinung nach ist das eine noch schlechtere Benutzeroberfläche.
Wenig bekannte Debatte, halten Sie die Überprüfungen auf!
Chris – Ich bin verwirrt, dass Sie sagen, dass Dropdown-Listen und Radio-Buttons im Grunde gleich sind, da Sie bei beiden nur 1 Option auswählen können.
Die Dropdown-Liste kann mehrere Auswahlen zulassen: http://www.w3.org/TR/html401/interact/forms.html#adef-multiple
Ich bin mir ziemlich sicher, dass Sie wissen, was ich meine. Wenn es sich NICHT speziell um eine Mehrfachauswahl handelt.
Ich denke, Shoutyman hat den Nagel auf den Kopf getroffen. Wenn „Wählen“ keine akzeptable Option beim Absenden des Formulars ist, sollte es auch keine Wahl in der Dropdown-Liste sein.
Wenn Sie eine Auswahl erzwingen müssen, ermöglichen Radio-Buttons, dass Sie nichts auswählen und machen es dennoch deutlich, dass etwas ausgewählt werden muss.
Die Tatsache, dass sie nicht zu „nichts ausgewählt“ zurückkehren können, ist – by Design – so gewollt. Es gibt keine Null-Geschlechtsoption mit Absicht. Etwas muss ausgewählt werden, also macht es keinen Sinn, den Benutzer wieder zum Zustand des Nicht-Auswählens zurückkehren zu lassen.
Verwandtes Szenario: Mein Vater ist sehr neu im Web. Neulich hatte er ein Problem, bei dem die Webseite einer Person abstürzte, bevor er sich vollständig für deren Dienst angemeldet hatte. Da er die Anmeldung nicht abgeschlossen hatte, aber sich wieder anmeldete, wurden einige Standardwerte verwendet. Sein Geschlecht wurde als „weiblich“ ausgewählt.
Mein Vater war wütend. Es dauerte etwa eine Stunde, bis er verstand, dass es kein direkter Angriff auf ihn war und nur ein einfacher Standard in ihrem System war, den er jederzeit ändern konnte.
Seltsamerweise passierte mir mit meinem Vater etwas sehr Ähnliches. Er ist dem Web gegenüber recht neu und ich ließ ihn allein ein Online-Versicherungsformular ausfüllen. Da er langsam tippte, lief sein Formular ab, bevor er es beendete, und als er auf Senden klickte, wurden alle Standardoptionen übernommen.
Zumindest wäre eine Folge davon, dass, wenn der Standardzustand „neutral“ wäre, dies die Formularvalidierung erleichtern würde, sodass so etwas nicht passieren würde?
Eigentlich möchte ich nicht, dass eine serverseitige Sitzung unnötig abläuft. Was in praktischer Hinsicht bedeutet, dass Sie überhaupt keinen serverseitigen Sitzungszustand hätten.
Es gibt keinen Grund, warum das bisher Eingereichte nicht von Seite zu Seite weitergegeben werden kann, solange es nicht abgeschlossen ist, bis es eine vollständige Transaktion ergibt.
Schnelle Frage
Wie würden Sie die von Ihnen anfangs gegebene Auswahl standardmäßig auswählen?
Manche Leute könnten* beleidigt sein, wenn Sie automatisch ihr Geschlecht für sie auswählen.
*(Ich argumentiere nicht, ob sie richtig oder falsch liegen, ich kenne nur einige Leute, die in einem ständigen Zustand der Dummheit leben)
Persönlich würde ich eine Dropdown-Liste mit drei Optionen erstellen. Geschlecht wählen, Männlich und Weiblich.
Für solche Dinge bin ich ein großer Fan von OPTGROUP – ich wünschte nur, Browser würden standardmäßig diesen Wert anstelle der ersten aufgeführten Option verwenden.
OPTGROUP ist eine gute Option, aber sie ist wirklich schwierig für die Barrierefreiheit. Wenn Sie die Gelegenheit haben, eine Seite mit OPTGROUP von einem Screenreader vorlesen zu lassen. Es ist ziemlich rau.
Das war auch mein erster Gedanke. Aber die Auswahl des Geschlechts ist eines der wenigen Beispiele, bei denen dies zutrifft. Nehmen Sie z. B. die Auswahl von Kreditkarten. Niemand würde sich hier beleidigt fühlen.
Sie könnten Links/Buttons in einem Assistenten-Stil verwenden oder Checkboxen und bedenken, dass beide als ungültiger Zustand markiert werden (wenn Sie wirklich Leute ignorieren wollen, die zu dieser Gruppe gehören).
Wenn wir HTML für einen Moment außer Acht lassen und rein die Benutzeroberfläche diskutieren, bin ich mir nicht sicher, ob ich der Festlegung einer Standardeinstellung in allen Fällen zustimme. Bei einem großen Formular ist das Problem bei der Wahl einer Standardeinstellung, dass die Anwendung nicht feststellen kann, ob der Benutzer das Feld übersprungen hat oder einfach die Standardeinstellung wollte.
Ich halte intelligente Standardwerte für *eine gute Sache*, verstehen Sie mich nicht falsch, aber es funktioniert nicht in allen Fällen. Ich gebe Ihnen ein Beispiel. Bei einer Hypothekenanwendung gab es eine Reihe von Ja/Nein-Fragen. Wir hätten Standardwerte festlegen können, wir haben sogar eine Schaltfläche, um sie auf „typische Antworten“ zu setzen, aber wir wollten den Benutzer warnen können, wenn sie noch nie tatsächlich festgelegt wurden. Mit unserer Anwendung können Sie Daten in beliebiger Reihenfolge eingeben und später darauf zurückkommen. Es ist für den Benutzer sehr nützlich zu wissen, dass er diesen Teil der Anwendung tatsächlich berührt hat.
Das ist ein großartiger Punkt.
Eine Sache, die hätte deutlicher gemacht werden sollen, ist ERFORDERLICH oder NICHT ERFORDERLICH. Wenn die Radio-Button-Gruppe ERFORDERLICH ist, ist es in Ordnung, wenn keine Standardauswahl getroffen wird, da der Benutzer sowieso aufgefordert wird, eine auszuwählen. Aber ein Feld als erforderlich zu kennzeichnen, geschieht typischerweise über serverseitige Verarbeitung oder Client-seitiges JavaScript.
Obwohl... HTML5 hat jetzt ein Attribut für erforderliche Eingaben. Ich wette, das spielt hier eine große Rolle.
Trotzdem habe ich fast das Gefühl, dass Radio-Buttons IMMER erforderlich sein sollten. Wenn sie optional sind, dann ist der unbestimmte Zustand die einzige Möglichkeit für „nicht auswählen“, was wir wissen, dass es unmöglich ist, in diesen Zustand zurückzukehren, sobald etwas ausgewählt wurde.
Während all diese Argumente gültig sind, muss ich stark auf dem Punkt der UX-Entwicklung im Gegensatz zu technischen Aspekten beharren. Formulare sind sehr interaktive Elemente innerhalb einer Anwendung und Sie müssen sehr sensibel für Ihre Zielgruppe sein.
Einfach zu sagen, dass alle Radio-Buttons erforderlich sein müssen, ist falsch. Einfach zu sagen, dass immer ein Standardwert für einen Radio-Button festgelegt ist, ist ebenfalls falsch.
Betrachten Sie die Frage im Kontext und den Wert dieser Frage. Erleichtert eine Standardeinstellung das Formular oder riskieren Sie, einen Benutzer zu beleidigen? Ist die Aktion des Auswählens dieser Option wertvoller als die schnelle Weiterleitung des Benutzers durch das Formular?
Ich denke, die Verwendung der männlichen/weiblichen Optionen in diesem Artikel war brillant. Beim Erstellen eines Formulars, was ist der Wert dieser Information? Ich habe viele Formulare ausgefüllt, die diese Frage stellen, und oft ist die Absicht rein Marketing und das ist für viele Leute SEHR frustrierend. Warum muss Facebook das wissen, wenn ich mich anfangs registriere, im Gegensatz dazu, wenn ich mich für einen medizinischen Dienst registriere? Sehen Sie, was ich meine?
Standardwerte und Standards sind großartige „Richtlinien“, aber als guter Entwickler müssen wir sensibel für Inhalt, Kontext und Anwendungsfall sein, bevor wir eine Reihe willkürlicher technischer Beschränkungen auferlegen.
das ist mein 2 Cent.
Es gibt Situationen, in denen ein anfänglicher unbestimmter Zustand perfekt Sinn macht. Wenn Sie versuchen, genaue Statistiken über die Besucher Ihrer Website zu sammeln, dann ist die Vorauswahl der beliebtesten Option definitiv nicht der richtige Weg. Viele Leute mögen es nicht, der „Randfall-Benutzer“ zu sein und denken eher, dass die vorausgewählte Antwort die Antwort ist, die sie wählen *sollen*.
Ich kann mir wirklich keine Situation vorstellen, in der ich dem Benutzer die Option geben möchte, zu einem nicht ausgewählten Zustand zurückzukehren. Wenn eine Frage nicht zutrifft, sollte dies eine ausdrückliche Option für den Benutzer sein, die er auswählen kann.
... dann sollte diese ausdrückliche Option auch der Standard sein, oder?
Eine solche Nicht-Auswahl zwingt den Benutzer zur Entscheidung. Wenn die Auswahl keiner der Optionen sinnvoll ist, liegt es am Entwickler, dies zu validieren und dem Benutzer Feedback zu geben. Dies zwingt den Benutzer, die Frage tatsächlich zu beantworten, wo bei einer vorausgewählten Option „männlich“ und einem weiblichen Benutzer, der die Frage übersieht, Ihre Daten falsch wären.
Mm, ich stimme zu – ich habe darüber nachgedacht, ob meine vorherige Aussage über kaputte Funktionalität ganz fair war (das ist sie nicht) und kam zum gleichen Schluss: In manchen/vielen Fällen ist eine Standardauswahl nicht weise *und* ein „Nicht-Wert“ ist nicht angemessen.
Normalerweise, wenn Sie Radio-Buttons verwenden, benötigen Sie eine Antwort, sonst kann der Benutzer nicht mit dem Formular fortfahren, da der Rest des Formulars auf diesem Wert reagiert.
BEISPIEL ( GESCHLECHT: Männlich oder Weiblich ) die restlichen Fragen im Formular könnten sich ändern, je nachdem, welches Geschlecht sie wählen.)
Wenn Sie wollten, könnten Sie ihnen eine dritte Option wie Shoutyman sie erwähnte geben, und sie könnte „Keine Antwort“ heißen.
Russell hat auch einen guten Punkt, aber wie Chris sagt, bräuchten Sie eine andere Verarbeitung (wie z. B. JavaScript), um den Benutzer zu benachrichtigen, dass das Feld nicht ausgefüllt wurde. Ich denke, wenn dies zu einem „Gesetz des Landes“ wird, sollte es stattdessen JavaScript oder serverseitige Verarbeitung hinzufügen, um die Standardauswahl zu entfernen, anstatt standardmäßig keine Wahl zu haben.
Es scheint, dass die kommentierten Meinungen IMO der Grund sind, warum wir manchmal als Designer (Autoren, Entwickler usw.) versagen. Warum verwenden wir den Begriff UI „Benutzer“ „Oberfläche“, ignorieren aber anscheinend den Benutzer in diesem Fall. Es wird spezifische Zeiten geben, in denen nicht ausgewählte Radio-Buttons benötigt werden. Das obige Beispiel „männlich und weiblich“ ist einer dieser Fälle.
In jedem Fall, in dem ich Radio-Buttons verwende, ist die Auswahl erforderlich. Im obigen Fall könnten Sie eine dritte Option hinzufügen und sie als „Möchte ich nicht sagen“ oder etwas Ähnliches bezeichnen.
Ich spreche nur aus der Sicht eines Benutzers, der nicht möchte, dass seine Wahl im Voraus getroffen wird. Eine Frau, die Ihre Website besucht und „männlich“ für sie ausgewählt hat, und sie muss „weiblich“ *über* „männlich“ wählen, klickt vielleicht einfach auf „zurück“. Nur ein Gedanke.
Ich weiß nicht, ob ich es gut finden würde, mindestens einen Radio-Button erzwingen zu lassen. Der Hauptpunkt von Radio-Buttons ist die Tatsache, dass sie nur einen auswählen können. Sie sollten nur validieren, um sicherzustellen, dass sie einen ausgewählt haben, wenn der Benutzer dies benötigt. Zum Beispiel: Die aktuelle Frage des Monats von css-tricks Umfrage. („Was ist Ihre serverseitige Sprache der Wahl?“)
Dies ist ein weiteres Beispiel, bei dem eine Auswahl erforderlich ist. Wenn eine Radio-Button-Gruppe erforderlich ist, ist es in Ordnung, wenn keine Standardoption ausgewählt ist.
Aber wenn sie NICHT erforderlich sind, wird es knifflig. Nehmen wir an, der Benutzer steht vor der MÄNNLICH / WEIBLICH-Auswahl. Er klickt auf männlich, entscheidet sich dann, dass er diese Frage eigentlich nicht beantworten möchte. Es gibt keine Möglichkeit, männlich abzuwählen, daher schlechte Benutzeroberfläche.
Wie oben erwähnt, könnte das manuelle Hinzufügen einer dritten Option für „Keine Antwort“ der beste/einzige Weg sein.
Ich glaube, das ist eine sehr gute Benutzeroberfläche.
Der Punkt von Radio-Buttons ist, den Benutzer zu „zwingen“, eine Option zu wählen. In einer gibt es IMMER eine ausgewählte Option (auch wenn sie leer, nutzlos oder ungültig ist).
Ich sah das immer als viel intuitiver an. Es zwingt den Benutzer, innezuhalten und zu wählen, und nicht nur „Oh toll, die Seite hat es für mich gewählt, ignorieren wir es“.
Radio-Button stellt genau das dar: Knöpfe an einem alten Radiomodell.
Erinnern Sie sich noch an die? Wenn nicht, fragen Sie herum. Das waren zur Auswahl des Sendefrequenzbandes: AM, FM und so weiter. Wenn man einen drückte, während ein anderer gedrückt war, sprang dieser heraus. Daher das Konzept der Option.
Aber wenn Sie nicht stark genug gedrückt haben, blieb der aktuelle Knopf nicht gedrückt, sodass keine Knöpfe gedrückt waren, daher der unbestimmte Zustand.
Wir sollten uns daran erinnern, dass analoge Systeme immer noch Modelle für Konzepte in der Benutzeroberfläche sind und wir versuchen sollten, sie zu verstehen und uns auf sie zu beziehen, auch wenn wir jetzt Touchscreens und Gesten haben.
Weil sie eine Bedeutung und strenge Funktionalität hatten, möchte ich hinzufügen. Alles war an seinem Platz und nichts wurde dem Zufall überlassen.
Keine seiner Tasten gedrückt zu haben, bedeutete, dass dieses Radio STUMM war, selbst wenn Sie mit der Lautstärke herumgespielt haben. Außerdem konnte es dann als Verstärker verwendet werden.
Heh, die Geschichten, die ich Ihnen erzählen könnte. Aber ich bin zu alt und brauche meinen Mittagsschlaf :).
Interessant, das wusste ich nie. Aufbauend auf der realen Analogie, wenn Sie ein altes Radio kaufen, sind sicherlich keine der Tasten gedrückt, sodass das Erste, was Sie tun, nachdem Sie es eingeschaltet haben, ist, ein Frequenzband zu wählen.
Ich vermute, dass dasselbe Konzept hier gilt. Wenn keiner der Knöpfe gedrückt ist, zwingt es Sie, eine Wahl zu treffen.
Das ist genau richtig. Und dann stimmt man fein ab, sucht nach seinem Radiosender, auf derselben analogen Skala, die im Grunde ein kleiner Faden hinter einem transparenten Kunststoff mit Skala war.
Ähnlich wie der .... Schieberegler. Heh, zweifeln Sie nie wieder an unserem technischen Erbe!
Aber zum Punkt, ich glaube, dass unbestimmt wirklich bedeutet, dass der Benutzer noch nichts mit der Gruppe gemacht hat, also kann diese Information manchmal auch nützlich sein. Bei der Validierung, prüfen Sie zuerst auf eine Option, ohne alle Radio-Buttons zu prüfen, sondern einen einfachen Wert für die Gruppe.
Ich meine damit,
- Wenn Sie ein Formular validieren, markieren Sie einige falsche Elemente rot
- Es wäre dann einfach, erforderliche Radio- oder Checkboxen rot zu markieren, die nie „berührt“ wurden.
Oder wie einfach es ist, den visuellen Stil zu ändern, sobald der Benutzer ihn „berührt“. Zeigt dem Benutzer, welche Änderungen er bisher am Formular vorgenommen hat.
Und das ohne neue Klassen hinzuzufügen.
Diese Art von Knöpfen findet man immer noch in Diners aus den 50er Jahren und in Antiquitätenläden. Ich finde es interessant, sich diese klassischen und zeitlosen Designs anzusehen, um zu verstehen, wie menschliche Interaktion funktionierte und wie viele Menschen sich mit neuen Designs, wie auf Webseiten, wohl fühlen mögen.
IMO ist dies ein weiteres Szenario im Webdesign, bei dem die Antwort ein eindeutiges *kommt darauf an* ist.
Führen Sie so viele UX-Tests wie möglich durch, um die beste Lösung für den Benutzer zu finden und gehen Sie damit weiter.
Einen Radio-Button standardmäßig ausgewählt zu haben, ist nicht immer eine gute Idee. Manche Leute könnten es als die bevorzugte/offensichtliche Wahl interpretieren und sie dadurch verärgern.
Wenn standardmäßig nichts ausgewählt ist, dann
1) Es ist optional, was problematisch ist, da es nach der Auswahl einer Option keine Möglichkeit gibt, sie wieder abzuwählen.
2) Es ist erforderlich, was voraussetzt, dass Sie Code zur Hand haben, um dieses „Erforderliche“ zu handhaben.
Wenn Sie eine Radio-Button-Gruppe in ihrem unbestimmten Zustand belassen wollen, dann darf sie besser nicht optional sein und Sie müssen darauf vorbereitet sein, Code zu schreiben, um die erforderlichen Dinge zu behandeln.
Ich wette, die Wahlergebnisse für den EU-Browser der Wahl wären sehr interessant, wenn eine Option standardmäßig ausgewählt wäre :)
Letztendlich ist das für die Markup-Struktur, oder? Also, ist es gut? Ja, für den unbestimmten Zustand müssen Sie keine neue Klasse hinzufügen.
Ist es für die Validierung? Nein, denn Sie validieren sowieso, richtig?
Dieser Radio-Button ist Teil einer Gruppe. Einen Standardwert für eine Gruppe zu haben, ist, als würde man mit einem bereits auf dem Stimmzettel aufgedruckten Stempel zur Wahl gehen. Es muss ein unbestimmter Zustand sein, damit er optional ist, es sei denn, er ist zwingend erforderlich. Aber auch dann validieren Sie, schlagen Sie nicht vor.
IMO.
Ich stimme der Validierung zu. Unabhängig von CSS/HTML sollte es immer client- und serverseitige Validierung geben.
Wenn Sie einen Standardwert haben müssen, dann müssen Sie Tabs oder Autocomplete/Kombinationsfelder verwenden. Es sind die Missbräuche des Konzepts, die schuld sind, nicht der Dreizustand eines Radios.
Sie, Radio-Buttons, stellen letztendlich einen Wert dar. Und der normale Zyklus für einen Wert ist: undefiniert, eingefügt/modifiziert, validiert.
Was das angeht
1) Es ist optional, was problematisch ist, da es nach der Auswahl einer Option keine Möglichkeit gibt, sie wieder abzuwählen.
können Sie einfach ein Radio zur Gruppe hinzufügen, das eine zusätzliche Option hinzufügt, die dieses Szenario behandelt.
Mein Englisch ist zu kaputt!
hmm, ich denke, Chris macht einige valide Punkte.
Wenn ich es wäre, würde ich wahrscheinlich nur Radio-Buttons mit einem unbestimmten Zustand für erforderliche Felder verwenden. Ansonsten würde ich wahrscheinlich ein Select-Feld für nicht erforderliche Felder verwenden.
Ich stelle mir vor, für eine Umfrage ist ein Select-Feld nicht sehr benutzerfreundlich und verursacht Probleme mit voreingenommenen Ergebnissen. Eine vorausgewählte Radio-Button-Option würde jedoch dasselbe tun, daher ist nur in diesem Fall ein unbestimmter Zustand sinnvoll, insbesondere weil zur Abstimmung eine Auswahl erforderlich ist.
Für eine nicht erforderliche Frage sollte die Option, nicht zu antworten, immer bestehen bleiben. Ich kann mir vorstellen, dass es sehr frustrierend wäre, versehentlich eine Frage zu beantworten und sie nicht wieder abwählen zu können. Eine Select-Box macht das einfach.
Ich denke, es ist eher eine Frage des richtigen Werkzeugs für eine bestimmte Aufgabe. Ein Radio-Button ist sicherlich sinnvoll für erforderliche Felder. Wenn Sie vom Benutzer eine Entscheidung erwarten (erzwingen).
Ich denke, die Aussage, dass Radio-Buttons ohne Standardauswahl eine schlechte Benutzeroberfläche darstellen, ist eher vereinfachend. Das trifft oft zu, aber nicht immer. Ob ein Feld erforderlich ist oder nicht, vielleicht möchten Sie, dass der Benutzer eine bewusste Entscheidung trifft. Die Bereitstellung eines erforderlichen Radio-Buttons mit einer Standardauswahl ist dasselbe wie ein optionales Feld, das Benutzer überspringen können. Manchmal möchten Sie das vielleicht nicht.
Ich denke nicht, dass es eine gute Idee ist, eine Designentscheidung zu treffen, die einen Standard ignoriert, nur weil jeder Browser, den Sie testen/unterstützen, den genannten Standard übersehen hat.
Wenn es wirklich wichtig ist, dass der Benutzer nicht von Ihren Standardwerten geleitet wird, oder wenn es für den Benutzer unpraktisch ist, seine Fehler später zu korrigieren*, geben Sie ihm eine Liste von Links oder Symbolen im Voraus, getrennt von der Massen-Datenerfassung. Dies könnte sogar mit der Massen-Datenerfassung kombiniert werden, wenn es mit JavaScript erweitert wird.
(*Komplizierte oder langwierige Formulare sollten eine Übersichtsseite haben, auf der der Benutzer prüfen kann, bevor er seine Daten übermittelt, wenn er das, was er senden möchte, nicht nachträglich ändern kann.)
Hallo Leute. Ich habe eine Frage, die ich nicht lösen konnte. Kann ich einen Radio-Button ansprechen, ohne ihm eine ID oder Klasse zu geben?
Hier ist, warum ich frage. Immer wenn ich einen Rand auf INPUT in meinem CSS setze, fügt es auch einen Rand zu den Radio-Buttons hinzu (in IE). Also muss ich allen Radio-Buttons eine Klasse geben und CSS für keinen Rand für diese Klasse hinzufügen. Es muss doch einen besseren Weg geben, oder?
Versuchen Sie es mit einem Attribut-Selektor
input[type=”radio”].
Danke!! Hat perfekt funktioniert! Ich bin viel zu aufgeregt deswegen ;)
Gern geschehen. Sie sollten wahrscheinlich Folgendes berücksichtigen
- input { border: none}
- Ziele per Klasse, ID oder anderer Mittel die Elemente an, die einen Rand benötigen
Den Rand von allen Eingabefeldern zu entfernen, ist ein wenig gefährlich, es sei denn, Sie haben einen guten Plan. Submit-Buttons haben standardmäßige Browser-Stile (wie den Gel-Button-Look in Webkit), die brechen, wenn Sie den Rand entfernen. Wenn Sie also vorhaben, diesen durch Ihren eigenen Button-Stil zu ersetzen, legen Sie los, ansonsten lassen Sie diese Browser-Standardeinstellungen bestehen.
Danke Chris.
Deshalb sagte ich, es müsse in Betracht gezogen werden, als Alternative, die andere Seite einer Münze.
Wie ein neuer Radio-Button in der Gruppe!
Chris hat mehrmals erwähnt, dass eines der Rätsel darin besteht, dass es keine Möglichkeit gibt, zum unbestimmten Zustand zurückzukehren.
1. Tut der gefürchtete Formular-Reset-Button nicht genau das?
2. Für Zeiten, in denen Sie möchten, dass Ihre Radio-Button-Gruppe zurückgesetzt wird, könnten Sie nicht einen dedizierten „Auswahl aufheben“-Button neben dieser Gruppe erstellen (mit JavaScript)?
Hast du gerade Reset-Button gesagt? *Seufz*
:)
Keine einfache Möglichkeit.
1. Der gefürchtete Formular-Reset-Button tut nichts Nützliches. Wenn Sie das Formular mit einem serverseitigen Fehler neu anzeigen müssten, würde der Reset-Button das Formular auf die neu angezeigten Werte zurücksetzen.
2. Wenn Sie sich auf JavaScript verlassen wollten, ja. Würde der durchschnittliche Benutzer den Button verstehen? Wahrscheinlich spielt es keine Rolle, wenn es etwas war, das der Benutzer tun konnte, könnten Sie genauso gut diesen Button als ersten Radio-Button nehmen und ihn zum Standard machen. Ihre Validierung kann den Benutzer zwingen, diese Option nicht zu wählen, wenn Sie das möchten.
Ich denke an das Männlich/Weiblich-Szenario und daran, dass es optional ist, wo „bevorzuge ich nicht zu sagen“ nicht anwendbar/angemessen für das Formular ist. Andernfalls wäre das die Standardoption. Auch hier geht es um Wege, um zum unbestimmten Zustand zurückzusetzen.
Ich habe nicht gesagt, dass ich den Reset-Button mag. ;) Es scheint eine Teillösung für die Frage zu sein.
Ich glaube, dass der unbestimmte Zustand ein Programmierer-Code für einen NULL-Wert (für eine Radio-Gruppe) ist, ein Wert, der NOCH NICHTS ist, also NICHT Null, NICHT leer. Das Abfangen hilft bei der Vorvalidierung.
Das können Sie mit einem Select-Element nicht erreichen. Wenn Sie jedoch einen neutralen Wert wünschen, zu dem ein Benutzer zurückkehren kann, kann dies mit nur diesem erreicht werden.
nützlich, wenn Sie keine Voreingenommenheit bei der Auswahl wünschen, danke!
Dieser Thread erinnert mich an die Diskussion über das Auswahlproblem „eins oder mehr“ in „Tog on Interface“ von 1992! Lustig, dass wir immer noch die gleichen Argumente führen, immer noch keine guten Lösungen...
HTML5 enthält eine idiotische Spezifikation. Überraschen Sie mich nicht.
Der gute Grund, eine Auswahl nicht zu erzwingen: Radio-Buttons werden in Umfragen verwendet. Eine erzwungene Standardauswahl verfälscht die Ergebnisse. Eine erzwungene Standardauswahl würde auch massiv ungenaue, aber technisch gültige Daten zulassen, wenn ein Befragter einfach nur durchklickt.
Wenn Sie Ihre Standard-Radio-Schaltfläche so festlegen, dass sie eine ungültige Antwort ist, vermeidet dies Voreingenommenheit. Sie müssen kein ungültiges HTML verwenden, als wäre es notwendig.
Wir sollten also einen Radio-Button mit der Überschrift „Sie haben noch nicht gewählt“ als Standard für jede von uns erstellte Radio-Gruppe hinzufügen? Das ist eindeutig unsemantisch und meiner Meinung nach wird es den Benutzer auch verwirren.
Es ist (meiner Meinung nach und aus UI-Sicht) viel sinnvoller, ein Styling anzuwenden, das die Aufmerksamkeit des Benutzers auf die Gruppe von Auswahlmöglichkeiten lenkt, die er noch nicht gewählt hat.
Ja, Sie werden die Eingaben validieren und ihn trotzdem explizit daran erinnern – aber *warum*, wenn Sie eine subtile, kontextbezogene Erinnerung geben und ihm die Mühe ersparen könnten? Wer geht lieber zurück und korrigiert Fehler bei einer Einreichung, anstatt es beim ersten Mal richtig zu machen?
Warum machen wir die Dinge so kompliziert??? Fakt ist, dass bei der Verwendung von Radio-Gruppen für die Auswahl des Geschlechts nur zwei Optionen bestehen: MÄNNLICH und WEIBLICH. Geben Sie ihnen keine Option für KEINE ANTWORT usw.
Eigentlich wurde ich einmal von der schwedischen Verbraucherbehörde rechtlich gezwungen, diese Unbestimmtheit auf ein Formular anzuwenden. Es handelte sich um einen Fall, in dem wir die Wahl einer Zusatzversicherung für ein Online-Reisebüro voreingestellt haben wollten, aber die Verbraucherbehörde zwang uns, keine Wahl für den Kunden zu treffen. Wir durften nicht einmal „nein“ als Standardwahl treffen...