Survey results regarding form controls and components

Survey Results from 2019-10 | 901 Unique Respondants
(not all respondants answered all questions)

Demographic of respondants

Usage of web projects

Top frustrations

Commonly used dropdowns

Key for the different types of dropdowns used that respondants selected

Verbatim Quotes

The following were provided under "Any other thoughts?" Most common themes were selected

  • "Get full support from all browsers"
  • "Multiselect should support a tag style selection mode and a line/row/checkbox mode (like today)."
  • "Accessibility must be at the forefront. Whatever customisation becomes possible must be 100% accessible and must have corresponding aria support etc"
  • "Just expose low-level primitives that are used to create focusable, interactive elements, similar to attachInternals for form-associated custom elements."
  • "Please help us!!"
  • "I like the approach of implementing these form inputs as web components/std imported modules. No need to necessarily change the existing <select> but if there were an std:select that had the kind of API that are expected of modern components that would be great (and I could ditch selectize..!)"
  • "Give it an explicit "unselected" state with look that users will understand. And search, search, search. Or add a country selector if you can't salvage select (I know you don't want to be in politics, so fix the select for country lists!)
  • "Just the flexibility of styling that I need..."
  • "Combine <select> and <datalist> into a complete solution - both are close but neither is perfect"
  • "Please prevent that people need solutions like Select 2 that will break the accessibility, by making the select and options better style-able with CSS."
  • "Making custom selects unnecessary seems like a first step before tackling typeaheads though I do love that plan."
  • "Controlling direction of the pop-up element (up, down, lef, right, vertical, horizontal) would be great. Support for nested dropdowns would be also great."
  • "Very glad to see there are movements around the select tag., so huge props to folks trying to move this forward as I know this won't be the easiest task. But just had to say it's time the web has a native select tag we can actually use and easily styled without implementing a custom one with 300 lines of JS, 100 lines of CSS and a huge dose of intersecting divs and span. So I can't wait to see any advancements on this."
  • "Do not turn it into a super-element. We absolutely need to allow styling, but anything more would be overloading the element. If we need to satisfy the autocomplete use case, we can combine other elements."
  • "Concentrate on the simplest styling issues first. If we can eliminate custom dropdowns in 90% of the cases that would be a huge win."
  • "No other recommendations—really happy that you all are thinking about working on this! :)"
  • "Expose a “toggle” event or “open”/“close” so I don’t have to reverse-engineer browser heuristics for what events open and close them"
  • "Introduce a dropdown element separate from the form semantics, which can be used for various purposes."
  • "One thing that I've found very hard when rolling my own is positioning in a manner that doesn't take the dropdown out of the canvas. Maybe something that automatigally makes the dropdown go to where there is space would be super helpful (as the native select already does)"