Firefox 53: Suchfeld in select-Feldern bei vielen Optionen
Das select-Feld des HTML-Standards erlaubt die Auswahl einer Option aus einer Liste. Je mehr Optionen diese Liste beinhaltet, desto schwieriger kann es sein, den gewünschten Eintrag zu finden. Eine Neuerung von Firefox 53 hilft in solchen Situationen.
Standardmäßig kennt das <select>-Feld des HTML-Standards keine Suchfunktion, so dass Anwender auf Webseiten mit langen Auswahllisten unter Umständen lange den gesuchten Eintrag suchen müssen. Firefox-Nutzer haben es ab Firefox 53 einfacher: dann nämlich zeigt Firefox bei <select>-Feldern mit mehr als 40 Optionen ein Suchfeld an. Dieses filtert die Liste noch während der Eingabe, so dass der Nutzer schneller zum Ziel kommt.
Die Neuerung ist bereits Bestandteil der Nightly-Version von Firefox 53, allerdings noch standardmäßig deaktiviert. Aktiviert kann die Neuerung werden, indem über about:config der Schalter dom.forms.selectSearch per Doppelklick auf true geschaltet wird. Die standardmäßige Aktivierung dieses Features kann in diesem Ticket verfolgt werden.
Sören Hentzschel ist Webentwickler aus Salzburg. Auf soeren-hentzschel.at informiert er umfassend über Neuigkeiten zu Mozilla. Außerdem ist er Betreiber von camp-firefox.de, der ersten Anlaufstelle im deutschsprachigen Raum für Firefox-Probleme aller Art. Weitere Projekte sind firefox.agenedia.com, mozilla.de, firefoxosdevices.org sowie sozone.de.
Das sollte HTML-Standard werden, habe ich öfters schon vermisst. Ich verwende auch sehr gerne + , was ja quasi das standardisierte „Gegenstück“ für Textfelder ist.
Gute Idee.
Wenn man aber bei +40 Einträgen ist, sollte man vielleicht seine Liste überdenken und anders strukturieren. 😉
Das kann man so nicht pauschal sagen. Eine Länderliste zum Beispiel besteht nun einmal aus weit mehr als 40 Ländern. 😉
Man könnte 2 Listen daraus machen und den größten gemeinsamen Nenner finden. Z.b. vorher den Kontinent auswählen.
Ich versteh schon den Sinn dahinter. Von daher, lieber haben als brauchen. 🙂
Die letzte Länderliste, die ich implementiert hatte, bestand aus 248 Ländern. Die Länder sind nicht gleichmäßig auf die sieben Kontinente verteilt, aber sagen wir mal der Einfachheit halber, es wäre so. Dann wären das immer noch über 35 Länder pro Kontinent, also beinahe 40. Bei korrekter Verteilung teilweise weniger, teilweise aber eben auch wieder mehr als 40. Das Beispiel ist selbst mit Unterteilung in Kontinente kaum unter diese Dimension zu bringen. 🙂
Eigentlich durchaus eine gute Idee, auch wenn man jetzt schon meist durch Eingabe des Anfangsbuchstabens schon mal ganz in die Nähe des Gesuchten kommt.
Und irgendwie sind die Suchergebnisse in diesem Fall hier nicht sinnvoll. Warum sollte bei Eingabe von "de" Kapverden und so aufgelistet sein? Das macht z.B. in einem Autocomplete Feld Sinn (alleine schon weil das mehrere Wörter sein können), aber nicht in einer solchen Auswahl.
Wieso sollte das keinen Sinn ergeben? "de" kommt nun einmal in "Kapverden" vor, alles andere würde also mit den offensichtlichen Nutzererwartungen brechen.
Ich weiß auch nicht, worauf du mit dem Zusammenhang hinaus möchtest, dass es bei einem Autocomplete Sinn ergeben würde, weil es dort mehrere Wörter sein könnten – auch in einem Select-Feld kann ein einzelner Eintrag problemlos aus beliebig vielen Wörtern bestehen.
Erst Kontinent auswählen ist ein Klick mehr. Und dann kommt noch das Problem dazu, in welchem Kontinent ist nun das gewünschte Land, nicht jeder hat den gleichen Bildungsstandard.
Ich würde bei diesem Beispiel eine Top 10 mit den vermutlich wichtigsten Länder oben platzieren und dann noch mal alle in alphabetischer Reihenfolge.
Grundsätzlich hat Sören recht, lange Listen sind nicht unbedingt ein Design Problem, manchmal sind sie notwendig.
Weil ich in einem Select-Feld ja eh sofort sehe, was verlangt wird. Ich sehe laos z.B. "Land". Nun tippe ich logischerweise die ANFANGSBUCHSTABEN des Landes, jenes ich suche. Niemand wird anfangen mit "schland" um Deutschland zu suchen.
Und wenn ich mal "de" getippt habe, will ich nur noch Länder sehen, welche mit "de" anfangen, nicht Kapverden, nicht Schweden.
Bei Autocomplete ist das anders. Ich weiß ja eventuell nicht mehr, in welcher Reihenfolge ich damals Wörter eingegeben habe. Habe ich jetzt "james bond spectre" oder "spectre james bond" drin? Hier macht diese Suche viel Sinn.
Das ist doch reine Theorie. Da wird man ja eh alle durchforsten müssen, ganz abgesehen davon wird solch eine Auswahl vermutlich niemals >40 Optionen anbieten.
Ich lasse mich aber gerne belehren, kannst ja gerne ein Beispiel posten. 😉
Und wenn du dir nicht sicher bist, wie ein Land geschrieben wird? Manchmal ist der Unterschied zwischen der Bezeichnung in der eigenen Sprache und in der Sprache des jeweiligen Landes ja auch nur ein einzelner Buchstabe. Länder sind außerdem ja ein eher einfaches Beispiel. Es gibt unzählige Möglichkeiten, was per <select>-Feld ausgewählt werden könnte.
So funktionieren solche Filter-Felder üblicherweise aber nicht.
Ich sehe immer noch nicht, was das mit Autocomplete zu tun haben soll. Diese Auswahl kann es auch ganz gewöhnlich in einem <select>-Feld geben und dann bist du in der genau gleichen Position, dass du nicht weißt, in welcher Form das nun als Option drin steht.
Was soll daran bitte reine Theorie sein? Eines von unzähligen Gegenbeispielen hast du gerade selbst genannt.
Dank Suchfeld kann man sich im Idealfall sparen, alles durchforsten zu müssen. Das ist ja der Sinn davon.
Ich habe auch keine Ahnung, wieso du glaubst, dass es keine <select>-Felder mit mehr als 40 Optionen, die jeweils aus mehr als einem Wort bestehen, geben sollte. Man kann mittels <select> alles in Listen abbilden, was man möchte.
Wir haben eine Webseite in der Firma auf der man den Produktionsstatus nachvollziehen kann. Es gibt circa 70 Maschinen, man wählt die Maschine aus an der man gerade steht (per select-Feld) und weiß was man abzuarbeiten hat.
Die Listeneinträge sind Maschinennummer + Name. Manche Merken sich nur die Nummer, machne den Namen. Momentan ist das per JS-Library implementiert und zwar genau so, dass enfach der String irgendwo im Listeneintrag vorkommen muss, genau aus diesem Grund.
Falsch. In vielen Dateimanagern funktionieren solche Filter anders, resp. man kann das konfigurieren.
Mein Beispiel war aber ein für Autocomplete. Um bei dem Beispiel zu bleiben: Kein Filmverleih würde in einem Select-Feld alle Bond Filme auflisten wo mich dann "Spectre" ans Ziel bringt. Deshalb: Theorie.
Anderes Beispiel: Eine Umfrage. Jetzt muß ich mir doch eigentlich eh durchlesen was zur Auswahl steh, eine Suche wäre ein Schuß ins blaue.
Aber eigentlich egal, häufig wird man >40 Optionen ja eh nicht begegnen. 😉
Die Kommentarfunktion scheint nicht korrekt zu funktionieren. Ich hatte im ersten Post zwei HTML-Tags vor und nach dem „+“ geschrieben (input + datalist, ursprünglich allerdings mit Größer-/Kleinerzeichen). Korrekterweise müssten die escaped werden. Scheinbar wurden die aber stattdessen knallhart nach dem Abschicken rausgelöscht.
Ich schrieb "üblicherweise" und nicht "ausnahmslos". Ich arbeite übrigens als Frontend-Entwickler, das mal nur am Rande.
Nur, weil du dir das Beispiel nicht vorstellen kannst, ist es damit nicht automatisch nur Theorie. Vor allem gibt es absolut keinen Grund, wieso man dein Beispiel als Autocomplete umsetzen können sollte, aber nicht als <select>-Feld.
Erstens hat niemand gesagt, dass man für ausnahmslos jeden Anwendungsfall ein Suchfeld benötigt, zweitens, selbst dann: wir reden von mindestens (!) 40 Optionen. Das heißt, selbst wenn man sich eh alle Optionen durchlesen muss und das getan hat, dann ergibt es immer noch viel Sinn, die Option, für die man sich entschieden hat, schnell finden zu können.
Häufig vielleicht nicht, selten aber auch nicht. Ich hoffe sogar, dass das immer angezeigt werden wird oder das Limit zumindest reduziert wird. Ich sehe darin einen großen Mehrwert nicht erst ab 40 Optionen.
Hier mag das der Fall sein, aber diese Funktion hat Mozilla nicht extra für eine Länderliste erstellt. Stelle dir eine Liste mit Musikern und Gruppen vor, von denen es eine Interpretation von Come Together gibt. Wüsstest du Ad hoc, ob dort die Beatles als „Beatles“ oder „The Beatles“ aufgeführt sind? In einer Mediathek sind Sendungen oft (auch) alphabetisch sortiert zu finden – ist das heute journal nun unter J oder unter Z („zdf heute journal“) zu finden?
In beiden Fällen ist es sinnvoll, auch nach Namensbestandteilen zu suchen.
^^^ Ganz einfach, ich benutze das Suchfeld, das es auf den meisten Seiten gibt.
Ein Webmaster, der mir >40 Optionen zum durchlesen an den Kopf wirft, gehört ein Tritt in den Hintern. 😉
Egal, wie gesagt, ich finde die Sache ja an sich auch gut.
Allerdings stimmt das Design, zumindest der Hintergrund ja nicht mehr. Stört mich nicht, und ist ja wohl alles auch noch in Bearbeitung.
Wie durch die bisherigen Kommentare deutlich geworden sein sollte, lässt sich das keinesfalls pauschal sagen, dass eine schlechte Umsetzung vorliegt, nur weil es viele Optionen gibt.
Was meinst du damit?
Der Hintergrund im Feld ist immer schneeweiß, egal was der Webmaster da eigentlich definiert hat. Zumindest bei mir war das so auf den getesteten Seiten.
Wenn da dunkler Hintergrund mit heller Schrift sein sollte, wird es schwierig. Außer die Schrift wird momentan auch immer auf schwarz geändert, ich habe keine entsprechenden Testseiten zur Hand.
Die Optionen eines <select>-Feldes können im Multiprozess-Firefox überhaupt nicht mehr gestaltet werden. Insofern hat diese Neuerung auch keinen besonderen Einfluss darauf – spätestens, wenn in deinem Firefox die Multiprozess-Architektur aktiv wird.
Ah, hast Recht. Ist auch weiß wenn dom.forms.selectSearch auf false ist, e10s aktivivieren reicht da schon..
Hm… Aber das kannst Du jetzt eigentlich als Webmaster nicht gut finden, oder doch?
Ehrlich gesagt, doch. Die Gestaltung von -Optionen war schon immer nur sehr eingeschränkt und vor allem nicht browserübergreifend und schon gar nicht betriebssystemübergreifend per CSS möglich. Dass Firefox hier in der Vergangenheit mehr erlaubte, sollte nicht darüber hinwegtäuschen, dass Änderungen daran wenigen Browsern vorbehalten waren. Chrome zum Beispiel kann das auch nicht darstellen. Denn in Chrome, genau wie in Firefox mit Multiprozess-Architektur, werden diese Optionen nicht vom Browser gerendert, sondern vom Betriebssystem. Ich begrüße normalerweise jede Änderung, welche die Darstellung von Webseiten zumindest browserübergreifend vereinheitlicht.
Ich nutze inzwischen die jQuery Select2 Bibliothek, um die Opt-Liste der Selectfelder zu gestalten. Select2 erzeugt ebenfalls so ein „Suchfeld“. Entstehen jetzt ab Firefox 53 zwei Suchfelder, wenn es mehr als 40 Optionen sind?
Nein, es gibt keine Probleme mit Select2. Da es ja für Webseiten gar nicht möglich ist, <select>-Felder derart zu bearbeiten, besteht der Trick von Select2 darin, Dummy-Elemente zu erzeugen und nur diese sichtbar zu machen. Dementsprechend hat die Neuerung von Firefox auch keine Auswirkung auf Select2.
Ich glaube, ich installiere mir mal eine Nightly-Version und probiere es aus. Kann ich den aktuellen Firefox (5.0.1?) und den Nightly-Version parallel laufen lassen?
Vielen Dank!
Grundsätzlich kannst du das gleiche Firefox-Profil nutzen, empfohlen ist das aber nicht. Beim Wechsel zwischen verschiedenen Versionen mit dem gleichen Profil können Probleme entstehen.
Du kannst nicht gleichzeitig mit zwei Firefox-Versionen auf das gleiche Firefox-Profil zugreifen.