Fact-checked by Grok 2 weeks ago

Drop-down list

A drop-down list is a () element that enables users to select one or more predefined options from a compact, expandable , typically triggered by clicking a or . When inactive, it displays only the currently selected value to conserve space; upon activation, it "drops down" to reveal the full list of choices, from which the user can make a selection. This design pattern is fundamental in software applications, websites, and forms, providing an efficient way to present multiple options without cluttering the . Drop-down lists emerged as part of the evolution of graphical user interfaces (GUIs) in the late and early 1980s, drawing from earlier menu systems in research environments like Xerox PARC's Smalltalk, which introduced fixed drop-down menus to support command selection. They gained prominence in commercial products, such as the computer released in 1983, which featured drop-down menus alongside icons and windows to facilitate intuitive interaction. By the mid-1980s, they became standard in operating systems like the Macintosh System Software; the in (1995) featured drop-down functionality. In web contexts, drop-down lists are implemented via <select> elements, standardizing their use since the early days of the web in the . Common variations include single-selection lists for mutually exclusive choices, multi-select options allowing multiple picks, searchable dropdowns with integrated filters for large datasets, and multi-level hierarchies for nested categories. They are employed in diverse scenarios, such as form inputs (e.g., selection), navigation menus, filtering tools, and panels, but design experts recommend limiting their use to avoid issues like problems and excessive in long lists. features, including and compatibility, are essential for inclusive implementation. Despite criticisms of being "clunky" when over-relied upon, drop-down lists remain a versatile staple in modern UI for balancing functionality and space efficiency.

Definition and Terminology

Core Definition

A drop-down list is a (GUI) control that allows s to select one option from a predefined set of mutually exclusive choices, with the selected item displayed in a compact field and the full list expanding or "dropping down" below it upon interaction, such as clicking a trigger button. This design conserves screen space by concealing unused options until needed, making it suitable for interfaces where displaying all choices simultaneously would cause clutter. While the standard form supports single selection, variants exist that permit multiple selections from the list. The core components of a drop-down list consist of a visible trigger element—typically a text field showing the current selection or a label paired with a drop-down icon—and a hidden list of options that appears when activated. The list presents items in a vertical, scrollable format if numerous, enabling users to browse and choose without altering the overall layout of the interface. Drop-down lists serve primary purposes in form inputs for categorical selections (such as choosing a from a list), navigation menus for accessing sub-options, and data entry scenarios requiring efficient option picking to maintain a clean . Visually, the expanded list positions itself below the trigger to align with natural reading flow, and it automatically collapses after a selection is made, updating the trigger to reflect the chosen value. This control is distinct from a , which integrates a drop-down list with an editable text field for custom entries beyond the predefined options.

Key Terms and Variants

A drop-down list, also known as a drop-down menu or select box, is a element that presents a list of selectable options upon activation, typically conserving screen space by hiding the options until needed. In , the term "select box" specifically refers to the HTML <select> element, which renders as a compact control expanding to reveal choices. Related platform-specific terms include "" for controls in Windows applications that combine an editable text field with a drop-down list (distinct from non-editable drop-down lists), and "picker" in design tools like , emphasizing its role in selecting from predefined items. "List box," meanwhile, denotes a visible, non-collapsible version in guidelines, though it overlaps with drop-downs when the list is initially hidden. Drop-down lists differ from pop-up menus in their activation and persistence: drop-downs emerge directly below or adjacent to a element, such as a , and close upon selection, whereas pop-up menus often appear as context-sensitive overlays triggered by right-clicks and may persist until explicitly dismissed. They also contrast with fields, which incorporate text input for filtering suggestions in rather than requiring a to reveal a full, non-editable list of options. Variants of drop-down lists are categorized by their content population: static lists contain fixed, predefined options entered manually during design, suitable for unchanging sets like status indicators. Dynamic lists, by contrast, are populated at runtime from external data sources such as databases or , allowing real-time updates like fetching current user preferences or levels. The term "drop-down" derives from the action of the list descending from the control upon activation.

Types and Functionality

Standard Single-Select

The standard -select drop-down list, also known as a select box, is a fundamental component that allows s to choose exactly one option from a predefined set of choices. When inactive, it displays a single or selected value in a compact field, often accompanied by a downward-pointing or to indicate expandability. Upon , such as a or on the , the component expands to reveal a vertically scrollable list of options below the field. Selecting an option updates the displayed text to that choice's label, closes the list, and commits the selection, ensuring only one value is active at a time. This mechanism is widely used in forms for fields like country selection or priority levels, promoting efficiency in by limiting choices to valid, enumerated options. Keyboard navigation enhances accessibility and usability in single-select drop-downs, typically supporting arrow keys to traverse the list (up/down to move, with highlighting of the current focus), and the Enter or Space key to confirm selection and collapse the list. This allows users to interact without relying solely on mouse or touch input, aligning with standard input conventions across platforms. For instance, in desktop environments, the list often gains focus via Tab navigation, enabling seamless progression through form elements. These navigation features are rooted in established UI standards to reduce cognitive load and support diverse user needs. Key attributes of single-select drop-downs include option labels for human-readable display, underlying values for programmatic data binding (e.g., distinguishing display text like "" from a code like ""), disabled states to gray out and prevent interaction with unavailable options, and the ability to set a default selection on initialization. Disabled options maintain visibility in the list but cannot be chosen, useful for temporarily invalid choices like out-of-stock items. Default selections can pre-populate the field with a common or previously chosen value, streamlining workflows, while the initial placeholder often reads as "Please select" or similar to prompt action. These attributes ensure flexibility in implementation while enforcing the single-choice constraint. Advantages of the standard single-select design lie in its space efficiency, occupying minimal screen real estate when collapsed compared to radio buttons or exposed lists, which is particularly beneficial in forms with multiple fields or on mobile devices with limited viewport space. By confining inputs to predefined options, it prevents invalid or erroneous entries, reducing form submission errors and backend validation needs. However, edge cases require careful handling: an empty list might display only the placeholder without expansion capability, signaling no options available; a list with a single option behaves more like a static label, often auto-selecting on trigger to avoid unnecessary interaction; and no-selection states preserve the placeholder until a choice is made, with validation to enforce mandatory fields. These considerations maintain robustness across varying data scenarios.

Multi-Select and Advanced Variants

Multi-select drop-down lists extend the basic functionality by permitting users to choose more than one option from the list, typically achieved through the multiple attribute on the , which presents the options in an expanded listbox format rather than a collapsed menu. Users select multiple items by holding the Ctrl key (or Cmd on macOS) for non-adjacent choices or Shift for a contiguous , with selected options often rendered as a comma-separated string or removable tags within the control for clear visibility. Advanced variants build on this foundation to handle complexity and scale. Searchable drop-downs, known as combobox patterns, integrate a text input field with the list, allowing users to type queries that filter and narrow the visible options in real-time, supporting behaviors such as list matching or inline completion to aid selection from predefined values. Hierarchical or nested lists organize options into grouped categories using elements like <optgroup>, where labeled sections contain sub-options (e.g., main product categories with subcategories), enabling structured navigation without nesting groups further to maintain simplicity. For large datasets, infinite-scroll variants dynamically load additional options as the user scrolls through the list, preventing performance degradation from rendering thousands of items at once while maintaining a seamless selection experience. These variants find application in scenarios requiring multiple inputs without cluttering the interface, such as tagging systems for content categorization, user preference settings in applications, or filters where selections like multiple brands or attributes refine search results efficiently. However, they carry limitations, including the risk of cognitive overload when options exceed 10–12 items, as users may struggle with overview and accidental dismissal during scrolling or multi-selection, necessitating strong visual indicators like checkboxes or selection counters for feedback.

Implementation in Technologies

Web Technologies (HTML and CSS)

In web technologies, drop-down lists are primarily implemented using the , which creates a for selecting one or more options from a predefined list. The <select> element contains child <option> elements, each representing a selectable item with a value attribute for the submitted data and text content for display. For grouping related options, <optgroup> elements can be used as containers within <select>. Key attributes include size, which specifies the number of visible options (defaulting to 1, showing a drop-down if less than the total options); multiple, a allowing multi-selection and displaying as a list box; required, enforcing selection of a non-empty option during form submission; and disabled, which prevents user interaction and grays out the . These attributes enable basic single-select functionality by default, with multiple supporting advanced variants. Customization of the <select> element via CSS is possible but historically limited due to native browser rendering, which prioritizes system UI consistency over full stylistic control. Developers can style the trigger (the collapsed view) using properties like appearance: none to remove default styling, border for outlines, and padding for spacing, while the expanded list can be influenced by background for color and max-height combined with overflow: auto for scrolling behavior when size exceeds one row. Hover and focus states are targeted with pseudo-classes like :hover and :focus for the <select> and <option> elements, allowing color changes or underlines. However, limitations persist, such as inability to fully restyle the drop-down arrow without experimental features, often requiring -webkit-appearance prefixes for partial control in WebKit-based browsers like Chrome and Safari. Recent advancements, starting in Chrome 135 (March 2025), introduce appearance: base-select to enable broader customization, including pseudo-elements like ::picker(select) for the trigger and support for rich HTML in <option> (e.g., SVG icons), though this remains experimental and non-standard across all browsers. JavaScript enhancements extend the native <select> functionality for dynamic behavior, such as populating options via the add() method or manipulating the options collection. Event handling includes the change event, which fires when a selection is confirmed (e.g., by clicking an option or pressing Enter) and the element loses focus, ideal for validation or updating related form fields. The focus event triggers on user interaction with the control, enabling scripts for dynamic population from APIs or databases. For older browsers lacking support for modern attributes or events, polyfills like those in libraries such as Select2 or Choices.js provide fallback implementations by replacing native <select> with custom HTML/CSS/JS constructs that mimic drop-down behavior. These enhancements ensure compatibility while maintaining semantic HTML structure. The <select> element has been supported since HTML 2.0 (1995), with universal availability across major browsers: since version 4 (2008), since 2 (2006), since 3.1 (2008), since 12 (2015), and since 6 (partial, full in 11). A modern addition is the <datalist> element (, supported since 2010 in most browsers), which pairs with <input> via the list attribute to offer hybrid autocomplete drop-downs—displaying <option> suggestions without restricting input to predefined values, unlike strict <select> controls. This provides a flexible alternative for web forms seeking drop-down-like suggestions with free-text entry.
html
<!-- Example: Basic single-select drop-down -->
<select name="fruit" required>
  <option value="">Select an option</option>
  <option value="apple">Apple</option>
  <option value="banana">Banana</option>
</select>

<!-- Example: Multi-select with size -->
<select name="colors" multiple size="3">
  <option value="red">Red</option>
  <option value="green">Green</option>
  <option value="blue">Blue</option>
</select>

<!-- Example: Datalist for hybrid autocomplete -->
<input type="text" list="browsers">
<datalist id="browsers">
  <option value="Chrome">
  <option value="Firefox">
  <option value="Safari">
</datalist>
For CSS styling example:
css
select {
  appearance: none; /* Removes default styling */
  border: 1px solid #ccc;
  padding: 8px;
  background: white;
}

select:focus {
  border-color: #007bff;
  outline: none;
}

select:open {
  max-height: 200px;
  overflow: auto;
}

Desktop and Mobile GUI Frameworks

In desktop GUI frameworks, the toolkit utilizes the GtkComboBox widget to enable user selection from a predefined list of choices, displaying the current selection while revealing a menu upon . This widget supports integration with tree models and cell renderers for customizable displays, though it has been deprecated in GTK 4.10 in favor of GtkDropDown. A streamlined , GtkComboBoxText, caters to simple text-based lists by abstracting the model-view complexity, allowing developers to append items via gtk_combo_box_text_append_text(), designate the active item with gtk_combo_box_set_active(), and respond to user changes through the "changed" signal emission. The framework's QComboBox employs a model-view to facilitate robust data binding, where the default QStandardItemModel manages items and a QListView subclass handles the dropdown popup, ensuring efficient updates across diverse data sources. Developers add options using addItem() or insertItem(), set the current selection via setCurrentIndex(), and capture modifications with signals such as currentIndexChanged(int). This structure promotes cross-platform portability while leveraging platform-native rendering for consistent . Microsoft's Windows Forms provides the ComboBox control, which merges an editable text field with a selectable list, configurable through the DropDownStyle property to enforce read-only behavior (DropDownList), allow editing (DropDown), or display a persistent list (Simple). Items are populated and manipulated via the Items collection, employing methods like Add() for insertion and Remove() for deletion, with data binding support for dynamic content. On mobile platforms, Apple's UIKit framework implements drop-down functionality via UIPickerView, a component-based control resembling spinning wheels where each "component" holds indexed rows of selectable values, ideal for hierarchical or categorized choices. It integrates with a data source protocol to supply row counts per component and a delegate to render titles, views, and handle selections, ensuring seamless native behavior. Android's Spinner serves as the native equivalent, presenting a compact button that expands into a dropdown list upon touch, populated through adapters such as ArrayAdapter from string arrays or custom data sets. Selections trigger the onItemSelected() callback from an OnItemSelectedListener, retrieving the chosen item via position for immediate processing. Mobile adaptations prioritize touch interactions by enlarging interactive areas to at least 44x44 points for finger precision and incorporating swipe gestures, particularly in wheel-style pickers like iOS's UIPickerView, where users scroll through options fluidly. These enhancements, including modal presentations for expanded views, integrate with platform-specific controls to minimize fat-finger errors and support gesture-based navigation on varied screen sizes. Cross-platform considerations in GUI frameworks highlight portability challenges, such as Qt's ability to maintain API consistency for QComboBox across Windows, macOS, , and mobile via native backends, though subtle rendering variations ensure platform-appropriate aesthetics without altering core functionality. In web-hybrid environments like , drop-down elements may deviate from native controls in responsiveness and visual fidelity, potentially requiring custom styling to approximate platform norms.

User Experience and Accessibility

Design Best Practices

Effective design of drop-down lists prioritizes by ensuring they integrate seamlessly into forms and interfaces, minimizing and errors. Placement should position the drop-down near related input fields to maintain contextual flow, such as alongside a shipping address for a selector. Labeling must use clear, descriptive prompts, like "Select " as the initial , to guide users on expected input and avoid ambiguity. For 5–15 options, a drop-down list is suitable, particularly when screen space is limited; for more than 15 options, prefer a listbox to display most options visibly and avoid excessive scrolling. Visual design elements contribute to intuitive by promoting and . Maintain uniform across drop-downs, with each option row ideally at 48dp height for touch targets, and ensure high-contrast text against backgrounds to enhance , especially in varied lighting conditions. Incorporate smooth animations, such as fade transitions with subtle downward motion on opening, to provide feedback without disorientation, while avoiding unnecessary icons that could clutter the interface unless they add essential context. Gray out unavailable options rather than removing them, displaying them in lighter text to indicate inaccessibility while preserving list structure. Interaction guidelines emphasize efficiency for diverse input methods. Support keyboard-only navigation, allowing users to type the first letters of options to jump directly to matches, which speeds selection in alphabetical lists. For longer or categorized lists, integrate search functionality with filtering to dynamically reduce options as users type, easing discovery in complex scenarios. Employ grouping via dividers or sections to organize related items, such as regional subdivisions under countries, improving scannability without overwhelming the user. Multi-select variants can extend these practices for scenarios requiring multiple choices, but they demand additional visual cues like checkboxes. Common pitfalls in drop-down design often stem from poor organization and inflexibility, leading to user abandonment. Always apply alphabetical or logical sorting—such as frequency-based for common choices—to ensure predictability, as random ordering forces exhaustive scanning. For cases where predefined options fall short, include an "Other" entry that triggers a free-text field for custom input, preventing forced selections and accommodating edge cases without disrupting the list. Avoid defaults unless a large portion of users (e.g., 90%) are expected to select that value, to prevent submission errors. Steer clear of drop-downs for fewer than five options, where radio buttons prove faster.

Accessibility Features and Challenges

Drop-down lists must comply with (WCAG) to ensure usability for people with disabilities, including using elements like the <select> tag for native dropdowns, which inherently convey structure to assistive technologies. For custom implementations, attributes such as aria-expanded to indicate open/closed states and aria-haspopup="listbox" to signal the presence of a selectable list enhance comprehension without overriding native semantics. Additionally, WCAG Success Criterion 1.4.3 requires text and background color contrast ratios of at least 4.5:1 for dropdown options and labels to support users with low vision. Screen readers like NVDA and provide robust support for native <select> elements by announcing the number of options, the currently selected value, and focus changes as users navigate with . This includes verbal cues for expansion and selection states, enabling users to efficiently choose from lists. However, custom JavaScript-based dropdowns often fail to expose these semantics, leading to challenges where screen readers announce only the trigger button without listing options, violating WCAG 4.1.2 (Name, , Value). To mitigate this, developers must apply roles like role="listbox" and role="option" to replicate native behavior. Keyboard navigation is essential under WCAG Success Criterion 2.1.1, requiring all dropdown functionality to be operable without a , using to focus the control, to traverse options, and or Enter to expand/select. Voice control users benefit from ARIA live regions (aria-live="polite") that announce dynamic updates, such as selection changes, to integrate with speech recognition software like . Traps in custom dropdowns, where focus cannot escape the open list without Esc, can trap users, but proper implementation allows sequential and closure. On mobile devices, WCAG emphasizes larger touch targets for dropdown triggers and options, recommending at least 24x24 CSS pixels under Success Criterion 2.5.8 (Target Size, Level AA in WCAG 2.2) to accommodate users with motor impairments, though best practices suggest 44x44 pixels to prevent mis-taps. feedback via platform APIs, such as Web Vibration API, can confirm selections for haptic users, but positioning challenges arise when expanded lists extend off-screen on small viewports, obscuring options for users with limited dexterity unless responsive design adjusts layout. These issues highlight the need for testing across devices to ensure equitable access.

Historical Development

Origins in Computing

The concept of drop-down lists, also known as pull-down menus, traces its roots to early interactive computing systems that emphasized efficient selection mechanisms for users. In the late 1960s, Douglas Engelbart's oN-Line System (NLS), demonstrated in 1968 at the Stanford Research Institute, introduced mouse-driven selection of on-screen text items and structured lists, laying foundational ideas for list-based interactions in collaborative environments, though primarily in a text-oriented interface. This work influenced subsequent developments by highlighting the need for direct manipulation of visible options to enhance productivity. During the 1970s, text-based precursors emerged in command-line environments, particularly within UNIX systems, where libraries like curses—developed at the —enabled the creation of menu-driven interfaces on character-based terminals. These allowed users to navigate hierarchical options via keyboard selections, addressing the limitations of pure command typing on low-bandwidth teletype devices. Such mechanisms were motivated by the need for usability in resource-constrained settings, where full-screen displays were unavailable, and they prefigured graphical lists by prioritizing space-efficient option presentation. The transition to graphical drop-down lists occurred in the 1980s with the advent of displays in systems. At PARC, the computer (1973) featured early pop-up menus as precursors, selectable via mouse on its 1024x808 screen, driven by the challenge of organizing commands within limited (approximately 72 DPI). This evolved in the workstation (1981), which introduced the first with pull-down menus—rows of labels that expanded to reveal hierarchical options upon selection—designed to conserve screen real estate on early office computers while supporting intuitive navigation. No single patent governed these innovations; instead, they stemmed from collaborative research at PARC, emphasizing for knowledge workers. Apple's Lisa computer (1983) formalized and popularized pull-down menus in personal computing, integrating a persistent at the screen's top for system-wide access to commands, building directly on influences to simplify interactions on its 720x364 display. Similarly, the , released in 1984 by , incorporated menu widgets as core elements, enabling developers to create pull-down structures for bitmap-based applications across networked Unix workstations, further standardizing the approach without proprietary claims. These early implementations were driven by the era's hardware constraints, such as monochrome screens and modest memory, where drop-down lists optimized visibility and reduced compared to sprawling on-screen clutter.

Evolution Across Platforms

The drop-down list, as a (GUI) element for selecting options from a constrained list, originated in early pioneering systems at Xerox PARC. The workstation, released in 1981, introduced one of the first implementations of drop-down menus as part of its WIMP (windows, icons, menus, pointer) paradigm, featuring a that triggered pop-up menus for commands like file operations. These menus were positioned at the top of the screen following user testing, emphasizing space efficiency and discoverability in a bitmap-display environment. This design addressed the limitations of text-based interfaces by allowing hierarchical option selection without overwhelming the workspace. Apple adapted and refined drop-down mechanisms in its early GUIs, building directly on innovations. The , launched in 1983, incorporated pull-down menus in a fixed at the screen's top, enabling users to access application commands via mouse clicks. This evolved further in the Macintosh System Software 1.0 (1984), which popularized the single, global with pull-down lists for consistent navigation across applications. Microsoft's (1985) followed suit, integrating drop-down menus in tiled windows and early like , standardizing the element for broader PC adoption by the late . These desktop evolutions prioritized mouse-driven interaction. In web technologies, the drop-down list materialized through the Mobile platforms adapted drop-down lists for touch interfaces, diverging from desktop norms to accommodate smaller screens and gesture-based input. Apple's , introduced in 2007 with the , eschewed traditional dropdowns in favor of UIPickerView wheels or action sheets—bottom-anchored modal lists—for selections like dates or priorities, prioritizing visibility and thumb-friendly scrolling over compact triggers. , launching in 2008, retained spinner widgets (exposed dropdowns) in its guidelines from 2014, allowing inline list expansion for quick picks, though evolving to include auto-complete and search-integrated variants by Android 5.0 (2014). These adaptations reflect platform-specific philosophies: iOS emphasizes contextual modals for immersion, while Android favors persistent, adaptive lists for efficiency, with both incorporating accessibility features like support by the .

References

  1. [1]
    Dropdown UI Design: Anatomy, UX, and Use Cases - Setproduct
    Aug 16, 2023 · Dropdown – is a user interface (UI) element that allows users to select one option from a list of available choices. Dropdowns are commonly used ...
  2. [2]
    What are Dropdown Menus?
    ### Summary of Dropdown Menus in UX Design
  3. [3]
    Dropdowns: Design Guidelines - NN/G
    Jun 11, 2017 · Summary: Dropdown boxes and menus are overused and clunky but can be useful for revealing a list of options or commands.
  4. [4]
    Graphical User Interface History - KASS
    Lisa was released in 1983 and the Mac in 1984. The GUI featured top drop down menus, overlapping windows, icons for programs and documents as illustrated in the ...
  5. [5]
  6. [6]
    Drop down list design: the complete guide - Justinmind
    Jan 29, 2024 · Drop down list design can make or break the user experience of your website or app. Find out how to make the best of them in this guide!
  7. [7]
    Windows 7 Drop-down Lists Combo Boxes - Win32 apps
    Feb 8, 2022 · A drop-down list is a list in which the selected item is always visible, and the others are visible on demand by clicking a drop-down button. A ...Guidelines · Drop-Down Lists · PromptsMissing: definition | Show results with:definition
  8. [8]
    Listboxes vs. Dropdown Lists - NN/G
    Apr 12, 2020 · Listboxes and dropdowns are compact UI controls that allow users to select options. Listboxes expose options right away and support multi-selection.
  9. [9]
    User-Interface Elements: Glossary - NN/G
    Feb 28, 2025 · Dropdown Menu (Pulldown Menu, Linear Menu) ... A type of expandable menu in which the options are displayed in a list that appears below the menu ...
  10. [10]
    Combo box and list box - Windows apps | Microsoft Learn
    Feb 26, 2025 · Use a drop-down list to let users select a single value from a set of items that can be adequately represented with single lines of text. · Use a ...Create A Combo Box · Item Selection · Make A Combo Box EditableMissing: definition | Show results with:definition
  11. [11]
    Dropdown menu (combo box) guidelines - Balsamiq
    A Dropdown menu (or Combo Box, Pull Down menu, Picker) gives you a list of items to select from. It's a common element in forms, setting pages, and quizzes.Missing: terminology picker
  12. [12]
    Menus - Material Design 2
    A dropdown menu is typically positioned below the element that generates it. Dropdown menu below menu icon, displaying additional actions for a new contact app ...
  13. [13]
    Predictive text or dropdown: which is better? | by Nick Gassman
    May 28, 2018 · A simple rule of thumb is that if there is a 'small' set of possible choices, then use a pre-populated dropdown.
  14. [14]
    How To Create a Drop-Down List in Excel: A Step-by-Step Guide
    Dec 20, 2023 · Excel drop-down lists come in two main types: static and dynamic. ​​Static drop-down lists are created by entering a list of values into the ...
  15. [15]
    How to create drop down list in Excel: dynamic, editable, searchable
    Sep 27, 2023 · Advantages: The main advantage of a dynamic drop-down list is that you won't have to change the reference to the named range each time the ...<|separator|>
  16. [16]
    dropdown - Wiktionary, the free dictionary
    Etymology. Deverbal from drop down ... Coordinate term: pull-down. Click the Colours button on the toolbar to show a dropdown menu of available colours.
  17. [17]
  18. [18]
    Combobox Pattern | APG | WAI - W3C
    A combobox is an input widget that has an associated popup. The popup enables users to choose a value for the input from a collection.
  19. [19]
    Infinite Scroll UX Done Right: Guidelines and Best Practices
    Mar 30, 2022 · The easiest way to improve infinite scroll is by marking the breaks between “new” and “old” items in the list. When a new batch comes in, we ...
  20. [20]
  21. [21]
    <select>: The HTML Select element - HTML | MDN
    ### Summary of Multi-Select Drop-Down Lists in `<select>` Element
  22. [22]
    The <select> element can now be customized with CSS | Blog
    Mar 24, 2025 · From Chrome 135, web developers and designers can finally unite on an accessible, standardized and CSS styleable <select> element on the web.
  23. [23]
    HTMLSelectElement: add() method - Web APIs | MDN
    Apr 7, 2023 · The HTMLSelectElement.add() method adds an element to the collection of option elements for this select element.
  24. [24]
    HTMLElement: change event - Web APIs | MDN
    Sep 25, 2025 · The change event is fired for <input>, <select>, and <textarea> elements when the user modifies the element's value.Syntax · Examples
  25. [25]
    HTML element: select | Can I use... Support tables for HTML5, CSS3 ...
    "Can I use" provides up-to-date browser support tables for support of front-end web technologies on desktop and mobile web browsers.
  26. [26]
    <datalist>: The HTML Data List element - MDN Web Docs - Mozilla
    Jul 9, 2025 · The <datalist> HTML element contains a set of <option> elements that represent the permissible or recommended options available to choose from within other ...
  27. [27]
    Gtk.ComboBox
    A GtkComboBox is a widget that allows the user to choose from a list of valid choices. It displays the selected choice and a popup for new choices.
  28. [28]
    Gtk.ComboBoxText
    A GtkComboBoxText is a simple variant of GtkComboBox that hides the model-view complexity for simple text-only use cases.Missing: documentation | Show results with:documentation
  29. [29]
    QComboBox Class | Qt Widgets | Qt 6.10.0
    A QComboBox is a compact way to present a list of options to the user. A combobox is a selection widget that shows the current item, and pops up a list of ...
  30. [30]
    ComboBox Control Overview - Windows Forms - Microsoft Learn
    The Windows Forms ComboBox control is used to display data in a drop-down combo box. By default, the ComboBox control appears in two parts.
  31. [31]
    UIPickerView | Apple Developer Documentation
    known as a component — has a series of indexed rows ...
  32. [32]
    Add spinners to your app | Views - Android Developers
    May 20, 2024 · Spinners provide a quick way to select one value from a set. In the default state, a spinner shows its currently selected value.
  33. [33]
    Pickers | Apple Developer Documentation
    The system provides several styles of pickers, each of which offers different types of selectable values and has a different appearance.
  34. [34]
    Menus – Material Design 3
    A menu's height should be at least one row less than the app's UI. UI showing 48 dp for each menu row and another 48 dp padding between menu ...
  35. [35]
    Combo boxes | Apple Developer Documentation
    Best practices · Populate the field with a meaningful default value from the list. · Use an introductory label to let people know what types of items to expect.
  36. [36]
    Web Content Accessibility Guidelines (WCAG) 2.2 - W3C
    Dec 12, 2024 · Web Content Accessibility Guidelines (WCAG) 2.2 covers a wide range of recommendations for making web content more accessible.How to Meet WCAG (Quickref... · Headings and Labels · Success Criterion 1.3.1
  37. [37]
    ARIA: menu role - MDN Web Docs
    Jun 23, 2025 · The menu is required to have an accessible name. Use aria-labelledby if a visible label is present, otherwise use aria-label . Either include ...
  38. [38]
    Fly-out Menus | Web Accessibility Initiative (WAI) - W3C
    Use fly-out (or drop-down) menus to provide an overview of a web site's page hierarchy. It removes the need for multiple page loads.
  39. [39]
    Understanding Success Criterion 2.1.1: Keyboard | WAI - W3C
    All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes.
  40. [40]
    Keyboard Accessibility - WebAIM
    Sep 26, 2022 · Select (dropdown) menu. ↑/↓ - navigate between options; Spacebar - expand; Enter/Esc - select option and collapse. You can also filter or jump ...
  41. [41]
    Understanding Success Criterion 2.5.8: Target Size (Minimum) | WAI
    The intent of this Success Criterion is to help ensure targets can be easily activated without accidentally activating an adjacent target.
  42. [42]
    How WCAG 2.0 and Other W3C/WAI Guidelines Apply to Mobile
    Feb 26, 2015 · Ensuring that touch targets are at least 9 mm high by 9 mm wide. ... menu items within left-aligned lists in drop-down menus for navigation.1. Introduction · 1.1 Wcag 2.0 And Mobile... · 1.2. 1 Uaag 2.0 And...
  43. [43]
    User Interface Design Issues for a Large Interactive System
    Dec 23, 1975 · The NLS Command Language 1d · 1. Delimiting command words · 2. Delimiting arguments · 3. Delimiting optional arguments, selection type, or command ...
  44. [44]
    The Mother of All Demos | Lemelson
    Dec 10, 2018 · The oNLine System (NLS)​​ Through the NLS platform, Engelbart and his colleagues developed many of the techniques of modern, interactive ...Missing: menus | Show results with:menus
  45. [45]
    [PDF] Introduction to the Unix Curses Library - Index of /
    Apr 8, 2011 · Development of the curses library was a major step in the evolution of Unix software.Missing: 1970s | Show results with:1970s
  46. [46]
    [PDF] Introduction to the Unix Curses Library - Denison University
    Jan 4, 2007 · Many widely-used programs need to make use of a terminal's cursor-movement capabilities. A familiar example is the vi (or the vim variation) ...
  47. [47]
    How the Graphical User Interface Was Invented - IEEE Spectrum
    Sep 1, 1989 · The production Xerox Star, in 1981, featured a further advance: a menu bar, essentially a row of words indicating available menus that could be ...
  48. [48]
    [PDF] The Xerox "Star": A Retrospective
    In April of 1981, Xerox introduced the 8010 "Star" Information System. Star's introduction was an important event in the history.
  49. [49]
    [PDF] Inventing the Lisa User Interface (1997) [pdf] - Bitsavers.org
    The Lisa hardware would have an. Apple II-style bitmap screen and graphics support for creating simple line drawings using Logo™-style instructions. The hard ...
  50. [50]
    [PDF] The X Window System
    Our goal was to make it reasonable to use windows for such things as individual menu items, buttons, and even individual items in forms and spreadsheets. As ...<|control11|><|separator|>
  51. [51]
    History of the Apple GUI - LisaOS - MacOS - myoldmac.net
    The Scrap for cutting and pasting. October 1980 Prototype. Pull down menu moved to the top of the screen. Horizontal and vertical scrollbars are attached to the ...
  52. [52]
    The Past, Present And Future Of Native HTML Form Controls
    Nov 18, 2020 · They were introduced in the HTML 2.0 specification in 1995, but, despite their early origins, the ease with which developers can style or ...
  53. [53]
    On mobile, when should I use which dropdown list equivalent?
    Jan 22, 2015 · Android have 4 possibilities and iOS 3: Spinners: works well on mobile and tablets and seems to be more often used in small list of options.Missing: history | Show results with:history