3.1 HTML Datalist vs. Select

Die folgenden Unterkapitel zeigen die Möglichkeiten, welche die HTML-Elemente input, option, datalist und select bieten. Zudem zeigen tabellarische Gegenüberstellungen die Unterschiede und Inkonsistenzen dieser in verschiedenen Browsern und Betriebssystemen auf. Hierbei liegt der Fokus mehr auf der Interaktion mit den Komponenten als auf der Darstellung.

3.1.1 Option

Die beiden Auswahlkomponenten – datalist und select – verwenden option-Elemente. Die einzelnen Optionen wie in Code 3.1 Zeile 1 besitzen ein value-Attribut und einen Inhalt – das Label. Alternativ ist das label-Attribut (Zeile 2 ohne das selected) zu nutzen. An die Stelle des Inhalts ist das Value zu platzieren. Firefox unterstützt diese Variante jedoch nicht. Das Weglassen von value und label führt dazu, dass beide den Wert innerhalb des öffnenden und schliessenden Tags erhalten. Diese Variante ist in Zeile 3 (ohne das disabled) verwendet.

<option value="dog"         > Dog   </option> 
<option label="Cat" selected> cat   </option> 
<option             disabled> Mouse </option>

Das HTML-Element kann das Attribut disabled oder selected erhalten. Code 3.1 Zeile 2 definiert durch eine selected Option den initial ausgefüllten Wert. Dieses Attribut funktioniert nur im Zusammenhang mit dem select-Container. Bei einem disabled Element – wie in Code 3.1 Zeile 3 – erscheint das UI ausgegraut. Dieser Eintrag lässt keine Interaktion zu.

Das Designen von options [1] beschränkt sich auf die Text-/Hintergrundfarbe, welche jedoch nur in Firefox funktionieren. Die anderen Browser lassen kein Styling der Auswahl-Elemente zu bzw. zeigen dieses nicht an. Es ist nur ein skalarer Text als Inhalt erlaubt. Das bedeutet, keine weiteren Verschachtelung von Elementen ist möglich. Als Eltern-Elemente sind select, optgroup und datalist erlaubt. Alle gängigen Browser unterstützen das option-Element.

3.1.2 Select

Das select-Element speichert Werte durch die einzelnen option-Kinder. Eine mögliche Anwendung ist in Code 3.2 ersichtlich.

<select name="animal" disabled>
    <option value="dog"  > Dog   </option> 
    <option value="cat"  > Cat   </option> 
    <option value="mouse"> Mouse </option>
</select>

Die typischen Attribute für Eingabefelder – wie disabled, name und required – sind bei einem Select ebenfalls verwendbar. Durch das disabled (Zeile 1) zeigt sich das Element in einer ausgegrauten Erscheinung. In diesem Zustand bietet das Select dem Nutzer keine Interaktionsmöglichkeiten mehr. Der Container – z. B. fieldset – vererbt dieses Attribut weiter an seine Kinder. Die form-Eigenschaft definiert das dazugehörige Formular. Der name (Zeile 1) stellt den Key für das Key-Value-Paar bzw. den Name des Feldes im Formular dar. Das required erzwingt eine Eingabe, um das Senden des Formulars freizuschalten. Für eine bessere Accessibility benötigt das Select eine id, um das Label zuweisen zu können. Standardmässig ist für dieses Feld nur eine einzelne Auswahl möglich. Durch die Ergänzung des Attributs multiple ist es möglich, mehrere Werte zu markieren. Bei einer Vorauswahl mehrerer Listenelemente durch selected muss die Komponente ein Multiselect sein. Wenn jedoch bei einem Single-Select mehrere Optionen das selected-Attribut enthalten, gilt das zuletzt Definierte als vorausgewählt. Das autocomplete funktioniert wie bei anderen Inputs, indem Vorschläge des User-Agent-Features auftauchen. Durch die autofocus-Eigenschaft sind Interaktionen mit dem Feld direkt nach dem Laden möglich. Die Definition des size-Attributs steuert die Anzahl sichtbarer Elemente. Der Default für Single-Selects liegt bei eins und für eine mehrfache Auswahl bei vier. Die – in Kapitel Bekannte Implementationen – definierten Browser unterstützen alle select-Attribute – ausser der size. Die meisten Mobile-Browser supporten die Grösse nicht.

Abgesehen von der Grösse ist die Umgestaltung des Elements browserunabhängig kaum möglich. Es gibt jedoch aufwendige Wege, den Inhalt zu klonen und durch Wrapper neu zu stylen. In diesem Fall ist es notwendig, die Logik und die Interaktionen für die Accessibility neu zu implementieren. Gewisse Stylings lassen sich anwenden, wobei aber nicht alle Browser diese in derselben Weise übernehmen. Durch die komplexe Struktur des Selects ist eine eigene Darstellung schwierig zu kontrollieren.

Der Inhalt [2] des Elements können options oder optgroups sein. Mehr zur optgroup kommt im nachfolgenden Unterkapitel. Die ARIA-Rolle gibt der Komponente die Funktion einer Combobox (ohne size & multiple) oder Listbox.

Die mehrfache Auswahl rein per Tastatur bietet in der Interaktion geringere Möglichkeiten als mit der Maus. Die Maus kann mit gedrückter Cmd- (Mac) bzw. Ctrl-Taste (Windows) weitere Elemente dazu selektieren. Mit dem Drücken der Shift-Taste lassen sich alle Elemente zwischen der ersten und der letzten Option markieren. Damit die zuvor markierte Auswahl erhalten bleibt, ist beim Anwenden beider Techniken der Bereich mit Shift zuerst auszuwählen. Für das Markieren mehrerer Werte mittels Tastatur ist es unabdingbar, zuerst zum ersten Element zu navigieren. Mit Shift und den Pfeiltasten ↑ und ↓ ist ein Bereich wählbar. Firefox unterstützt noch die einzelne Mehrfachauswahl über die Tastatur. Auf dem Mac sind die Tastenkombinationen Systembefehle. Daher gibt es keine Alternative, als sie zuvor auszuschalten bzw. umzustellen.

3.1.2.1 Optgroup

Die optgroup dient als Zusatzelement. Das Element gruppiert die Optionen in einem select und versieht die enthaltenen options mit einem Zwischentitel. Der Titel lässt sich durch das label-Attribut – wie in Code 3.3 Zeile 2 – setzen, ist aber nicht selektierbar.

<select name="animal">
    <optgroup label="Big animal">
        <option value="dog"> Dog </option>
        <option value="cat"> Cat </option>
    </optgroup>
    <optgroup label="Small animal" disabled>
        <option value="mouse". > Mouse   </option>
        <option value="hamster"> Hamster </option>
    </optgroup>
</select>

Das disabled ermöglicht das Ausgrauen eines ganzen Blocks von Auswahloptionen. In Code 3.3 ist dies auf Zeile 6 zu sehen. Die Optionen, welche in diesem Element enthalten sind, erben das Attribut. Als Inhalt dienen option-Elemente und selbst besitzt es als Eltern-Element ein select. Die optgroup besitzt die ARIA-Rolle einer Gruppe. Alle Browser unterstützen dieses Element.

3.1.3 Datalist

Wie in Code 3.4 ersichtlich besteht die Datalist aus zwei Elementen – einem Input-Feld und einem Daten-Container. Die Datenliste besitzt keine speziellen eigenen Attribute. Das Element benötigt von den globalen Attributen zumindest eine id (Zeile 3). Die Id dient zur Verknüpfung der Liste mit dem Input-Feld. Das folgende Unterkapitel Input beschreibt das Eingabefeld und dessen Typen im Detail.

<input type="text" name="animal" 
       list="data" placeholder="Animal" />
<datalist id="data"> 
    <option> Dog   </option> 
    <option> Cat   </option> 
    <option> Mouse </option>
</datalist>

Das Stylen der datalist [3] ist sehr begrenzt bzw. nicht möglich. Der Datencontainer reagiert nicht auf den Zoom des Browsers. Gewisse Screenreader ignorieren die Vorschlagsliste und lesen diese dadurch auch nicht vor. Das Element erhält die ARIA-Rolle einer Listbox.

Die options einer datalist besitzen normalerweise nur ein value-Attribut und kein Label. Bei einer zusätzlichen Label-Definition kann das je nach Browser zu abweichenden Darstellungen kommen. Während Firefox nur das Label in der Liste anzeigt, visualisieren die anderen Browser das Label und das Value gemeinsam. Die Browser, welche Label und Value anzeigen, heben den Wert ein wenig hervor.

Die Darstellung kann zu Missverständnissen führen, da das Eingabefeld bei einer Auswahl nur das Value anzeigt. Die options-Werte können sich dem Typ des Inputs anpassen. Generell unterstützen alle Browser die datalist, aber Firefox nur begrenzt.

Nicht alle Browser unterstützen die Datenliste für jeden Eingabe-Typ [4]. Der textuelle Typ funktioniert in allen Browsern und die Liste öffnet sich nach einem Klick bzw. Doppelklick auf das Feld. Vordefinierte Datum- und Zeittypen funktionieren nur in den Chromium-basierten Browsern. Firefox und Safari zeigen den normalen Eingabe-Container, als ob die Liste nicht verknüpft ist. Bei der Verwendung einer Liste mit einer Range zeigen alle Browser die Optionen durch Markierungen auf dem Slider an. Die Kombination einer datalist mit einer Farbpalette zeigt eine breite, aber unterschiedliche Unterstützung. Unter den gängigen Browsern ist Firefox auf OSX der einzige, welcher die Liste nicht darstellt. Zusammengefasst bieten Chromium-basierte Browser für Listen mit den unterschliedlichsten Typen die beste Unterstützung.

3.1.3.1 Input

Dieser Abschnitt behandelt nur den Teil, welcher in Bezug auf die datalist von Belang ist. Das list-Attribut verknüpft das Input – in Code 3.4 auf Zeile 1 und 2 – mit den Auswahloptionen der Liste. Bei der Verwendung zusammen mit der datalist ist dieses Attribut Pflicht. Dadurch erscheinen die Auswahloptionen während der Bedienung des Input-Feldes.

Dieser Paragraph behandelt die in diesem Kontext für alle Typen geltenden Attribute. Das autocomplete-Attribut dient zur Anzeige der Hinweise für das Autofill-Feature des Browsers. Das disabled schaltet die Interaktionsmöglichkeiten aus und deaktiviert somit die Komponente.Ist das Eingabefeld ausserhalb eines Formulars platziert, kann das form eine Verknüpfung zu einem existierenden Formular herstellen. Im abgesendeten Formular dient die Eigenschaft name zur Identifizierung des Wertes im value-Attribut. Der Typ des Eingabefeldes – angegeben durch type – definiert, welche UI-Erscheinung das Input erhält und welche Werte zulässig sind. Als Standard-Typ ist text definiert, wodurch dieses Attribut optional ist. Mehr zu den für diese Arbeit wichtigen Typen ist im Unterkapitel Input-Typen mit Datalist-Unterstützung zu lesen. Die globale id dient bei den Eingabefeldern zusätzlich zur Verknüpfung mit einem Label-Element und somit einer besseren Accessibility.

Weiterhin existieren die zwei Attribute readonly und required Diese sind bei allen Typen – ausser range und color – definiert. Durch die Ergänzung der ersten Eigenschaft ist der Wert nicht mehr änderbar. Das Input bleibt aber im Verlauf der fokussierbaren Komponenten enthalten. Das required erzwingt eine Eingabe. Die Eigenschaften min, max und step unterstützen die Konfiguration der numerischen Typen [5]. Die ersten beiden begrenzen die Werte auf einen Bereich oder ein Intervall. Mit step lässt sich die Grösse eines Schrittes einstellen. Die textlichen Felder [6] besitzen die Attribute maxlength, minlength, pattern und size. Diese Texttypen zusammen mit number können durch placeholder einen Patzhaltertext erhalten. Die Min- und Max-Länge schränken die Textlänge der Eingabe ein. Die Vorgabe eines Regex-Musters im pattern-Attribut kann die Eingabe weiter eingrenzen. Das Formular validiert die Felder vor dem Senden anhand des Patterns und markiert fehlerhafte Eingaben als invalide. Gewisse Typen – wie z. B. url, tel und email – haben bereits ein Pattern hinterlegt. Mit size lässt sich die Grösse bzw. Anzahl sichtbarer Zeichen angeben. Weitere Informationen zum Styling eines Input-Feldes stehen im Unterkapitel CSS für Input-Felder.

Das Input besteht aus einem selbstschliessenden Tag. Die ARIA-Rolle ist vom Typ abhängig und ist einer Textbox, Combobox, Spinbutton, Slider, Searchbox, Telbox oder keiner speziellen Rolle zuzuordnen. In den hier erwähnten Möglichkeiten der Komponente existiert eine grossflächige Browserunterstützung. Die einzigen Ausnahmen beziehen sich auf die Typen week und month, welche im Firefox und Safari nicht funktionieren.

Input-Typen mit Datalist-Unterstützung

Bei den textuellen Typen [7] existieren text, search, number, email, url und tel. Diese Typen erscheinen mehr oder weniger als normales, einzeiliges Texteingabefeld. Die Ersten zwei der Auflistung verwalten einen Text ohne spezielle Anforderungen. Der Typ number dient zum Speichern der Werte als Zahlen und zeigt dies durch die Ergänzung zweier Buttons im UI-Feld. Die letzten drei Typen sind Textfelder, welche bereits ein passendes Pattern für E-Mail, URL oder Telefonnummer hinterlegt haben. Zudem zeigen diese Felder bei dynamischen Tastaturen ein der Situation angepasstes Layout [8]. Typen in der Kategorie Date-Time sind month, week, date, time und datetime-local.

Bei einer ungefähren Eingabe einer Zahl auf einem Intervall bietet sich range an. Im UI zeigt sich diese Komponente als Slider, wobei sich der Standardwert in der Mitte findet. Zur Festlegung der Limiten dienen min und max. Für eine Farbauswahl kann der Typ color zur Anwendung kommen. Die gängigen Browser zeigen nach dem Aufklappen Farbpaletten, welche sich aber in der Darstellung unterscheiden. Firefox beispielsweise greift auf die vom System gestellte Farbpalette zurück, wo Chromium-basierte Browser eine eigene bieten.

CSS für Input-Felder

Bei einem Input [9] bestehen mehrere Möglichkeiten, dieses umzugestalten. Es existieren eigene CSS-Pseudo-Klassen, wobei die folgende Aufzählung nur einen Ausschnitt aufzeigt.

• :enabled bzw. :disabled – reagiert auf das disabled-Attribut

• :read-write bzw. :read-only – reagiert auf das readonly-Attribut

• :valid bzw. :invalid – reagiert beim Abschicken des Formulars auf die Client-Side-Validität [10] des Felds

• :user-invalid – reagiert beim Verlassen des Inputs auf die Client-Side-Validität des Felds

• :in-range bzw. :out-of-range – reagiert auf das min- und max-Attribut

• :optional bzw. :required – reagiert auf das required-Attribut

• :blank – reagiert, wenn ein Feld leer ist

Weiterhin gibt es noch das Pseudo-Element ::placeholder, welches das Stylen des Platzhalters erlaubt. Das CSS-Property caret-color färbt den Cursor [11] in Inputs um. Im Gegensatz zur datalist und dem select lässt sich das normale Eingabefeld relativ gut designen.

[1] (contributors, 2023) [2] (contributors, 2024c) [3] (contributors, 2024a) [4] (contributors, 2024a) [5] date, month, week, time, datetime-local, number, range [6] text, search, url, tel, email, password [7] (contributors, 2024a) [8] z. B.: @ und . ist bei email immer sichtbar, oder bei tel sind die Zahlen besser dargestellt [9] (contributors, 2024b) [10] Einhaltung der Regeln für das Input – z. B. ein gegebenes pattern [11] blinkender Strich in einem Eingabefeld

Hier sind die Gegenüberstellungen der bereits vorhandenen Möglichkeiten zur Darstellung einer Optionsauswahl aufgelistet. Eine Gegenüberstellung der möglichen Funktionalitäten zeigt die Grenzen dieser Elemente auf. Dabei spielen die UI- sowie die Interaktionsunterschiede dieser Komponenten in verschiedenen Browsern eine tragende Rolle.

Als Basis dieser Arbeit dient das Country Select. Unter dem Country Select ist das Resultat der Vorarbeit zu verstehen. Weiter existieren bereits die Elemente Buttons bzw. Links, select und datalist. Die folgende Tabelle 3.1 zeigt einen Vergleich der genannten Möglichkeiten.

Tabelle 3.1: Vergleich der Auswahlmöglichkeiten

[1] Filter: Liste verändern je nach Anzahl passender Werte [2] Suche: Liste unverändert; Erster zu der Eingabe passender Wert aus der Liste

Nebst den in der Tabelle aufgeführten Möglichkeiten existieren diverse Libraries und Frameworks. Viele dieser Lösungen für Auswahlkomponenten besitzen Abhängigkeiten zu weiteren Bibliothekskomponenten. Durch das Einbinden der Frameworks bläst sich der eigene Code extrem auf. Diese Auswahlkomponenten bieten eine Menge an Funktionen an, welche jedoch die Anwendung sehr komplex machen. Die Einarbeitung dauert lange. Da das Ziel dieses Projekts eine schlanke und einfach verwendbare Komponente ist, sind die existierenden Frameworks keine Lösung. Dieser Bericht legt keinen weiteren Fokus auf externe Bibliotheken.

3.3 Länderauswahl-Komponente

Alternativ zu den bekannten HTML-Elementen datalist und select existiert eine weitere, spezielle Auswahlkomponente. Die Länderauswahl [16] ist das Resultat des vorausgegangenen Projekts. Diese vereinfacht die Selektion eines Landes in einer vorgegebenen Liste. Die Komponente ist jedoch nur auf den spezifischen Anwendungsfall – die Wahl eines Landes – getestet. Das Design, die Funktionen und die Anwendung unterscheiden sich aber von den oben genannten HTML-Elementen.

3.3.1 Design

Die Länderauswahl erscheint moderner als die alten HTML-Elemente. Die Komponente ist in geschlossenem Zustand durch einen immer sichtbaren Container (Abbildung 3.10) visualisiert. Darin befindet sich das gewählte Land. Ist die Länderauswahl geöffnet, erscheint ergänzend ein Listencontainer mit allen Ländern (Abbildung 3.11). Der Aufbau zeigt sich in einem Spaltendesign – Kontinente links und Länder rechts.

Das Design lässt sich einfacher und vielfältiger als bei den Standard-HTML-Elementen anpassen. Die einzelnen Subkomponenten besitzen Klassen, welche ein einfaches Umstyling ermöglichen. Funktionell zeigen sich sowohl Übereinstimmungen als auch Unterschiede.

3.3.2 Funktionen & Interaktionen

Ein grosser Unterschied findet sich in der Funktion des Kontinents. Durch die Selektion eines Kontinents reduzieren sich die zur Auswahl stehenden Länder. Ist kein spezifischer Kontinent ausgewählt, fällt die Selektion auf All. Die Komponente besitzt kein integriertes Formularfeld und benötigt deswegen in dieser Anwendung zusätzlichen Aufwand.

Die Länderauswahl bietet viele Interaktionen, welche sich bei den HTML-Elementen wiederfinden. Die folgende Tabelle 3.9 zeigt die Interaktionen, welche auf der Komponente implementiert sind.

Tabelle 3.9: Aktionen bei der Länderauswahl-Komponente

[*] Änderung der Selektion bewirkt Änderung des Highlights auf den selben Wert [*] Highlight und Cursor-Position besitzen selben Wert; kein Unterschied

[1] Suche: Erster mit dem eingegebenen Symbol passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ keine Aktion; Liste unverändert; nach Pause / Debounce-Ablauf ⇒ neue Suche

In der Bedienung existieren keine Browser-Inkonsistenzen. Die Interaktionen lehnen mehr an denen des Selects als denen der Datalist an. Zudem betreffen die Änderungen in der Länder-Spalte nur das Highlight [17] und nicht die Selektion. Die Selektion benötigt eine Bestätigung mit Enter oder Space.

3.3.3 Anwendung

Diese Komponente benötigt in der Anwendung kein HTML. Die Einbindung findet via JavaScript statt. Der folgende Code 3.5 zeigt einen möglichen Anwendungsfall.

const container = document.querySelector("#inputContainer");
if (null != container) {
    const countryList = [
        {
            country  : "Austria",
            continent: "Europe",
        },
        /* more country objects */
    ];
    const structureDetail = {
        value      : "",
        placeholder: "Choose a country",
        label      : "Country",
        name       : "country",
    };
    const structureMaster = {
        elementList   : countryList,
        sectionElement: { continent: "All" },
        focusObject   : {},
    };
    const detailController = ChoiceDetailController(structureDetail);
    const masterController = ChoiceMasterController("continent", "country")(structureMaster);
    const view = projectChoiceInput(detailController, masterController, "countryInput");
    container.append(...view);
}

Wie im Code 3.5 ersichtlich, sind mehrere Zeilen für die Erstellung der Komponente notwendig. Zudem befindet sich die Länderauswahl noch im experimentellen Status. Wie das Unterkapitel Future Features aus dem Bericht [18] der Vorarbeit beschreibt, gibt es noch Verbesserungspotenzial in der Implementation. Da diese Komponente noch nicht lange existiert, ist sie noch in keinem realen Anwendungsfall im Einsatz.

[16] (Marti und Burki, 2024) [17] Die Länderauswahl unterscheidet nicht zwischen Highlight und Cursor-Position. [18] (Marti und Burki, 2024)

3.4 Anwendungsfälle

Die Standard-HTML-Elemente finden in vielen Webapplikationen ihre Anwendung. Das bekannteste Beispiel eines Selects ist die Auswahl des Geschlechts. Diese Verwendung ist abgesehen vom Design unproblematisch. Ein anderer Anwendungsfall ist die Auswahl eines Jahres oder eines Geburtstags mit drei Selects. Das Ausfüllen dieser Situation gestaltet sich schon unangenehmer. Dies liegt daran, dass die Suche nach dem gewünschten Wert besonders beim Jahr eher lange dauern kann. Besonders mühsam gestaltet sich für Nutzer die Suche nach dem Herkunfts- bzw. Zielland aus einer Liste von ca. 250 weltweit. Aber auch den Wohn- oder Destinationsort aus mehreren 100 bis 1'000 (je nach Anwendungsgebiet) auswählen zu müssen, ist sehr zeitaufwendig. Die Datalist mit der eingebauten Filterfunktion bietet auf den ersten Blick eine angenehmere Anwendung. Das Problem ist jedoch, dass in den meisten Fällen eigene Eingaben unerwünscht sind. Als ebenfalls schlechte Alternative bietet sich das Select als Auswahlkomponente an. Damit zieht sich die Suche nach einem bestimmten Wert in die Länge – speziell wenn die Optionen nicht in alphabetischer Reihenfolge vorliegen. Selbst die Zuhilfenahme der Select-Suche [19] ist nicht in jeder Situation hilfreich. Ein weiteres Anwendungsgebiet findet sich in gewissen Webshops bei den Filter- und Sortierfunktionen wieder. Die Komponente zeigt sich unter anderem bei der Auswahl einer Grösse, Farbe oder Kategorie. In diesem Beispiel können viele Optionen bzw. Werte ohne klare Reihenfolge in einer Liste auftauchen. Dies führt dazu, dass das Auffinden des gewünschten Werts eher schwerfällt. All die oben genannten und noch weitere Fälle zeigen verschiedene Probleme auf. Die neue Komponente ermöglicht es, die unangenehmen Situationen aufzulösen. Mehr Informationen dazu sind im nachfolgenden Kapitel zu lesen.

[19] Durch das Drücken der Anfangsbuchstaben des gesuchten Wertes springt die Selektion zur passenden Option

3.2 Browser-Inkonsistenzen

Die Komponenten Select & Datalist variieren sowohl in der Ansicht als auch in der Interaktion. Die Unterschiede sind system-, browser- und komponentenabhängig. Nachfolgend sind die Inkonsistenzen genauer erläutert.

3.2.1 UI-Unterschiede

Das Select ist in der geschlossenen Form auf der rechten Seite mit mindestens einem Pfeil nach unten ausgestattet. Safari (OSX und iOS) verwendet als Icon einen Doppelpfeil (Abbildung 3.1). Firefox zeigt das Feld in Grau (Abbildung 3.2). Chrome und Edge verwenden hingegen einen weissen Hintergrund (Abbildung 3.3). Safari auf iOS stellt die Komponente ohne Rahmen dar und deswegen ist der Hintergrund in einem hellen Grau gehalten. Da der Fokus dieser Arbeit auf der Desktop-Anwendung liegt, finden sich die Bilder der Mobile-Browser im Anhang C.

Die geöffnete Liste ist bei Firefox als Einziges relativ konsistent. Sie erscheint in einem grauen Container. Die anderen Browser sind einstellungsabhängig. Sie zeigen den Container weiss oder dunkelgrau (Abbildungen 3.4 und 3.5) an. Je nach Anzahl der enthaltenen Elemente erscheint die Liste darunter (darüber) oder überdeckt die Detail-Ansicht. Am wenigsten lässt sich das Element in Safari stylen.

Da nicht jeder Browser ein Icon anzeigt, ist die Datalist weniger konsistent. Safari und Firefox stellen keinen visuellen Hinweis (Abbildungen 3.6 und 3.7) auf die Liste dar. Safari auf iOS zeigt hingegen in jedem Fall – bezogen auf den textuellen Typ – einen nach unten zeigenden Pfeil an. Andere Browser blenden auf der rechten Seite beim Hovern oder beim Besitzen des Fokus das Icon (Dreieck nach unten zeigend) ein.

Bei Firefox unterscheidet sich das Öffnen der Liste ebenfalls. Wenn das Feld den Fokus noch nicht besitzt, benötigt es zwei Klicks. Die anderen Browser lassen die Liste bereits beim ersten Klick erscheinen. Die Liste selbst verhält sich je nach Browser und Inhalt verschieden. Sie erscheint seitlich oder darunter (darüber). Die Übernahme des Dark- bzw. Light-Modes als Container-Farbe hängt vom Browser und dem Anwendungskontext ab. Die Liste überdeckt das Eingabefeld nie. Die Abbildungen 3.8 und 3.9 zeigen Beispiele der geöffneten Datalist.

Ein Blick auf die mobilen Browser wie iOS-Safari, Android-Firefox und -DuckDuckGo zeigen weitere UI-Unterschiede. Für eine bessere Bedienbarkeit zeigen sich die geöffneten Selects auf Android – gegenüber den Desktop-Versionen – in einem anderen Design. Die Liste öffnet sich als Dialog-Popup und füllt je nach Anzahl der Werte fast das komplette Display aus. Das selektierte Element besitzt einen ausgefüllten Radio-Button auf der rechten Seite. Auf iOS-Browsern erhält die ausgewählte Option auf der linken Seite ein Check-Icon (✓). Der Listen-Container erscheint ähnlich zum OSX-Browser als Dropdown-Liste. Nach einer Auswahl schliessen die mobilen Selects automatisch.

Die Datalist zeigt ihren Inhalt nur bei der Interaktion mit Pfeil auf der rechten Seite. Abgesehen von der Grösse der einzelnen Einträge für die Bedienbarkeit unterscheiden sich diese kaum von den Desktop-Versionen. Die Selektionen erscheinen gegenüber den anderen Optionen in keinem speziellen Design.

Weitere Inkonsistenzen sind in den Bildern im Anhang C zu sehen. Die nachfolgenden Abschnitte 3.2.2 bis 3.2.6 beschreiben die möglichen Interaktionen. Die Tabellen stellen Datalist, Single- und Multiselect einander gegenüber. Im Anschluss an die Gegenüberstellungen der Browser weist das Kapitel Fazit auf die Inkonsistenzen hin.

3.2.2 Edge Browser

Die folgende Tabelle 3.2 zeigt den Vergleich der typischen Interaktionen in Edge auf Windows. Der Vergleich folgt zwischen der Datalist, dem Single- und dem Multiselect. Auf Windows verhält sich Edge sehr ähnlich wie Chrome, da die Codebasis beider Browser Chromium ist.

Tabelle 3.2: Vergleich Interaktion Datalist & Select in Edge (Windows)

[1] Blinkender Strich in einem Eingabefeld [2] Filter: Input-Begriffe and-verknüpft enthalten; Liste verändern je nach Anzahl passender Werte [3] Suche: Erster zu der Eingabe passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ letzter noch übereinstimmender Wert; Liste unverändert; nach Pause / Debounce-Ablauf ⇒ neue Suche [4] Wert von dem size-Attribut [5] Verhalten der CSS-Position fixed

3.2.3 Chrome Browser

Die Gegenüberstellung 3.3 beschreibt die Bedienungsmöglichkeiten der drei existierenden Auswahlkomponenten in Chrome. Dabei spielt das System (Windows oder Mac) nur bei der Tastenkombination und nicht bei der Reaktion eine Rolle. Auf dem Mac verhält sich Chrome ähnlich wie auf Windows, Designaspekte können sich unterscheiden.

Tabelle 3.3: Vergleich Interaktion Datalist & Select in Chrome (Mac / Windows)

[1] Blinkender Strich in einem Eingabefeld [2] Filter: Input-Begriffe and-verknüpft enthalten; Liste verändern je nach Anzahl passender Werte [3] Suche: Erster zu der Eingabe passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ letzter noch übereinstimmender Wert; Liste unverändert; nach Pause / Debounce-Ablauf ⇒ neue Suche [4] Wert von dem size-Attribut [5] Verhalten der CSS-Position fixed

3.2.4 Firefox Browser

Die nachfolgende Aufstellung 3.4 zeigt die Reaktionen auf gewisse Benutzerinteraktionen in Firefox. Wie auch auf Windows zeigt Firefox auf dem Mac konsistentes Verhalten, jedoch mit typischen OSX-Designanpassungen. Die Interaktions-Feedbacks auf Mac können sich leicht von der Windows-Version unterscheiden.

Tabelle 3.4: Vergleich Interaktion Datalist & Select in Firefox (Mac / Windows)

[1] Blinkender Strich in einem Eingabefeld [2] Filter: Leerschlag als normales Symbol gezählt; Liste verändern je nach Anzahl passender Werte [3] Suche: Erster zu der Eingabe passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ letzter noch übereinstimmender Wert; Liste unverändert; nach Pause / Debounce-Ablauf ⇒ neue Suche

3.2.5 Safari-Browser

Die Interaktionen auf Safari sind in der Tabelle 3.5 einander gegenübergestellt. Der Apple-Standard-Browser zeigt zu den bisher gesehenen Vergleichen die grösste Abweichung.

Tabelle 3.5: Vergleich Interaktion Datalist & Select in Safari (Mac)

[1] Blinkender Strich in einem Eingabefeld [2] Filter: Leerschlag als normales Symbol gezählt; Liste verändern je nach Anzahl passender Werte [3] Suche: Erster zu der Eingabe passender Wert aus der Liste, wenn Eingabe nicht passend ⇒ sortiert nachfolgender Wert; Liste unverändert; nach Pause / Debounce-Ablauf ⇒ neue Suche [4] Wert von dem size-Attribut

3.2.6 Browser auf Andriod & iOS

Der Vergleich der Tabellen 3.6 und 3.7 zeigt, dass auf Android-Geräten Abweichungen existieren. Nicht alle Bedienungsmöglichkeiten führen zur selben Reaktion.

Tabelle 3.6: Vergleich Interaktion Datalist & Select in Firefox (Android, Mobile)

[*] nicht möglich: Virtuelle Tastatur ist nicht sichtbar, somit kann keine Interaktion stattfinden

Tabelle 3.7: Vergleich Interaktion Datalist & Select in DuckDuckGo (Android, Mobile)

[*] nicht möglich: Virtuelle Tastatur ist nicht sichtbar, somit kann keine Interaktion stattfinden

[1] Filter: Leerschlag als normales Symbol gezählt; Liste verändern je nach Anzahl passender Werte; nicht scrollbar

Im Gegensatz zu den oben gezeigten Andriod-Browsern zeigen die meisten iOS-Browser die datalist und die selects auf derselben Basis an. Der iOS-Safari – als Stellvertreter – zeigt den Vergleich in Tabelle 3.8 auf.

Tabelle 3.8: Vergleich Interaktion Datalist & Select in Safari (iOS, Mobile)

[*] nicht möglich: Virtuelle Tastatur ist nicht sichtbar, somit kann keine Interaktion stattfinden

Wie in den Tabellen 3.6 bis 3.8 zu sehen ist, erlauben Mobilgeräte weniger Interaktionen als Desktop-Computer. Zum einen stellen die verschiedenen virtuellen Tastaturen eine geringere Auswahl an Interaktionen an. Auf der anderen Seite öffnet sich die virtuelle Tastatur nicht in jeder Situation. In Bezug auf die Komponenten Select und Datalist öffnet sich die dynamische Eingabemöglichkeit nur durch das Input der Datalist. Dies ist der Grund, wieso in den drei oben dargestellten Tabellen keine Tastatur-Interaktionen bei Selects möglich sind. Die Unterschiede bei der Datalist entstehen dadurch, dass nicht jeder mobile Browser die Liste bei Tastatureingaben offen lässt bzw. öffnet. Dadurch erklären sich die unterschiedlichen Verhaltensweisen, welche in den Tabellen ersichtlich sind.

Die Touch-Bedienungen auf der Datalist weisen kaum eine Übereinstimmung auf. Das Scrollen wie auch das Klicken verhalten sich bei den ausgewählten Mobile-Browsern Safari, Firefox und DuckDuckGo unterschiedlich. Das Select zeigt sich in der Interaktion mit dem Finger konsistenter.

3.2.7 Undo/Redo

Die Tastatur-Interaktionen Undo\footnote [12] und Redo [13] verhalten sich in allen Desktop-Browsern gleich. Beim Select – Single als auch Multi – passiert nichts. Im Input-Feld mit der Datalist reagieren die Aktionen auf den geschriebenen Text. Die einzige Ausnahme ist Safari, welcher das Undo/Redo auf Browserebene ausführt. Das bedeutet, die Interaktion betrifft nicht nur das fokussierte Eingabefeld, sondern alle Änderungen im Browser wie das Schliessen von Tabs.

Von den Mobilgeräten unterstützt nur das iOS-System via Schüttel-Bewegung das Undo bzw. Redo. Der iOS-Safari Browser zeigt dieselbe Reaktion wie Safari auf dem Desktop.

3.2.8 Fazit

Die Gegenüberstellungen der existierenden HTML-Elemente zeigen einige Gemeinsamkeiten, aber auch viele Inkonsistenzen. Da die Unterschiede ein Grund für die Entwicklung einer neuen Auswahlkomponente sind, fasst dieser Abschnitt diese nochmals zusammen. Im UI existieren über die vier Browser Edge, Firefox, Chrome und Safari sowie die Systeme OSX und Windows teilweise grosse Inkonsistenzen. Das System-Theme [14] spielt für die Darstellung ebenfalls eine grosse Rolle. Hierbei spielen das betriebssystemspezifische Styling und die individuellen Implementierungen der Browser eine Rolle. Der Fokus dieses Abschnitts liegt auf der Interaktion. Das UI ist bereits im Kapitel UI-Unterschiede genauer beschrieben.

Zwischen Edge und Chrome bestehen keine gravierenden Inkonsistenzen. Dies liegt daran, dass die beiden Browser mit derselben Rendering Engine [15] arbeiten. Zwischen Mac und Windows bestehen nur die systemspezifischen Unterschiede wie die zu drückenden Tasten (z. B. Home vs. fn & ←).

Firefox unterscheidet sich von Chrome in mehreren Interaktionen. Während die offene Datalist auf Firefox mit ← und → zwei unterschiedliche Reaktionen zeigt, reagiert sie im Chrome auf dieselbe Weise. Das Multiselect zeigt in den beiden Browsern ebenfalls inkonsistentes Verhalten. Die Enter-Taste löst auf Firefox im geschlossenen Single-Select nichts aus, während Chrome die Liste öffnet. Dafür reagiert Firefox im Multiselect auf Tab (Input verlassen), wo Chrome kein Verhalten zeigt. Die Interaktionen PageUp/-Down zeigen sich sowohl bei Datalist als auch beim Select unterschiedlich. Der eine Browser verwendet die View-Höhe als Mass zum Überspringen der Elemente und der andere das size-Attribut. Im geschlossenen Zustand des Single-Select überspringt die Selektion ebenfalls eine unterschiedliche Anzahl Elemente. Bei der Interaktion mit der Maus weist das Scrollen auf beiden geöffneten Elementen Inkonsistenzen im Verhalten auf.

Safari zeigt gegenüber den oben angesprochenen Browsern die grösste Abweichung. Einige Aktionen ändern anstelle der Selektion nur das Highlight. Zu den Chromium-basierten Browsern – wie Chrome – ist der Apple-Browser am ähnlichsten. PageUp/-Down zeigt bei den Einzelauswahl-Elementen ein komplett anderes Verhalten. Beim Single-Select ist die Reaktion dieselbe wie beim Drücken von Home/End. Die einzige Interaktion, welche nicht von den anderen Browsern abweicht, ist das Klicken auf ein Element.

Über verschiedene Plattformen hinweg erschweren die inkonsistente Darstellung und Funktionalität dieser Komponenten eine einheitliche Benutzererfahrung. Für eine optimale User-Experience ist die Konsistenzprüfung unabdingbar. Diese Erkenntnisse legen den Grundstein für die Entwicklung einer neuen, optimierten Auswahlkomponente. Diese soll die bestehenden Probleme adressieren. Die bereits erstellte Länderkomponente löst die Inkonsistenzen. Details dazu folgen im nächsten Kapitel.

[12] Ctrl & Z auf Windows; Cmd & Z auf Mac [13] Ctrl & Y auf Windows; Cmd & Shift & Z auf Mac [14] Dark- bzw. Light-Mode; auf Systemebene oder Browserebene einstellbar [15] Mehr dazu steht im Kapitel Browser & HTML-Renderer