There are too many needlessly reimplemented components, but anyone that has ever needed to style a <select> to make it look in line with any modern design quickly reached desperation.
I'd love to be able to use standard components everywhere, but most of my users care if my website looks like it's from 2004.
Example, a multi-select, see https://jsfiddle.net/z0Ltxh47/1/ :
Usability is bad because I can't select multiple non-consecutive items by using just my mouse. It's very narrow by default, and doesn't allow me to resize.
API: Your typical HTMLInputElement.value doesn't give me all the selected values. I need to map the .selectedValues to their values, or innerText if no value exist. Horrific.
Accesibility: At least in Firefox, using ctrl+arrows to be able to focus on elements to select them do not render any focus targets. In Chrome, the contrast is not there.
Don't even get me even started with the date/time-picker.
It is a hard concept that isn't completely solved by any of the standard GUI widgets.
Well you can with ctrl-click. A well hidden feature though.
> The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as <select> dropdowns, checkboxes, radio buttons, and date/color pickers.
Their current thinking is to cook a new element, <selectmenu>. Here's a demo of styling it in an experimental version of Chrome. https://www.youtube.com/watch?v=IjHnmaquifM
(They went with a new element <selectmenu> instead of <select styleable=true>, but there's still an ongoing debate about that, and/or how to polyfill it.)
You're declaring this based on what, exactly?
And as a developer I often need to argue with the designer that please just don't use dropdown on mobile ui when there are many items. That is just a torture for a phone user.
And sometimes I even need to add hidden area to the ui. Because the controls are way too tiny to click.
Usability are not really in their mind., Or probably it is just a bad designer.
And I get where they're coming from.
At the same time... native browser controls work, they don't require maintenance, they don't add to the bundle size, or have complex version inter-dependencies.
Maybe it's time to rethink frontend. Maybe what we write should be designed to work with the standard HTML controls.
(Or maybe it's time for me to go back to the backend and play with database, because I feel increasingly out of touch).
and this is by design, web as a platform is pretty much owned by tech giants like google and apple who have a financial interest in keeping the web from becoming a rich platform which would cut into their app store hegemony.
ironic when you consider iphone and the html 5 back story. in some respects microsoft with IE back in the days was more interested in developing the web as a platform but also saw the web as something they could monopolise whereas now apple takes a more nuanced but just as much devious approach.
Google is guilty of plenty of things, but holding back the web as a first rate development platform is not one of them, and I think the blame falls squarely on Apple's shoulders here.
Just look at what you can do with a PWA on Android. Most importantly, unlike on iOS, you can receive push notifications. But you can also do things like ship a PWA directly to the Play Store, access all sorts of native browser libraries like Bluetooth support and Add to Home Screen.
If you look at non-gaming apps, I'd estimate about 90% of them could be straightforwardly implemented as PWAs. The reason they're not is due to deliberate decisions by Apple not to support the tech that would make that possible, like push notifications.
Then don't make it look "in line with any modern design". Make it look like an HTML select tag, because that's what it is.
Functionality should (nearly always) trump prettification. (Especially when the results are pretty anyway).
Take a look at the search page.
It's true, and it really shouldn't be as controversial an opinion as it apparently is.
That would go a long way, but doesn't support more complex UI like checkboxes in the dropdown (for a compact multiselect component), a treeview instead of a listbox (including checkbox support), and highlighting parts of option text for things like autocomplete (with the ability to filter based on what's being typed).
It would also be useful to know if the listbox is being displayed above or below the select, so with a rounded border, you can style both the select input and listbox to have a flat edge on the top or bottom accordingly.
For checkboxes, it should be possible to theme them more easily, including: 1. border width, colour, and radius for the box; 2. a graphic or unicode character for the checked and mixed states; 3. optionally an image for the entire checkbox.
Character in chinese requires multi keystroke. And the IME won't be even triggered when you are not focusing a text field, render the whole function useless.
So, a common pattern here is "use combobox instead". Because combobox has a working input field build-in, make it usable with chinese.
But.... the HTML don't have combobox build-in, so you end up get one in literally any ui framework or a handwritten one if you really don't want to use framework.
Yes, it does. Supported in browsers since 2010, specified earlier. You have not taken the time to research this topic.
<input list="administrative_areas" name="PRC_AA" />
<datalist id="administrative_areas">
<option value="华北">
<option value="东北">
<option value="华东">
<option value="中南">
<option value="西北">
<option value="西南">
</datalist>
Just use normal components. Save the effort, help the screen reader, please the power user. Please.
The most accessible component library that I've seen is Adobe Spectrum React[1] which supports all of those nuances mentioned here for all of their controls and allow for styling and customization.
[1] https://react-spectrum.adobe.com/react-spectrum/index.html
I don't believe it.
Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour.
The invisible input field behaviour Drew mentions in the article doesn't work. If I hit backspace, my browser doesn't know I'm in an input field and (correctly) navigates me to the previous page.
In Firefox, if I use tab I can select my native <select> and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing.
I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether.
> It's such a blanket statement to say "you can't".
It's a blanket statement, sure, but in my experience it's absolutely true and I don't know why it's always frontend JS developers who are arrogant enough to think they can reinvent decades of work on e.g. Gtk in their crappy UI controls library but it's quite tiresome. Spoiler alert: you can't and won't, stop trying.
Took me exactly three key presses. I navigate using vimium. I just don't know how to pick anything on vimium without my mouse on this, while standard select work just fine.
I just tried the link (in Firefox) and all of these work correctly.
> I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether.
What do you mean, "click in the empty space before a form control"?
Any initial impressions on that one?
E.g. imagine if someone is using a modified Gtk library that uses vi-like shortcuts/modes for multiline text areas. This wont work on custom JS controls. Or something more likely, someone using macOS which, AFAIK, has text edit controls that understand some Emacs-like shortcuts. Even if you sniff their OS from the user-agent or whatever and use macOS-like keys, the user still wont get the text functionality exposes via, e.g. the Services menu.
Of course at the end of the day you may not care about such details - or care but you consider other things more important or have other concerns/limitations for the entire underlying system.
In a lot of cases, yes.
However, there are some controls, like date and color inputs, whose browser implementations are both inconsistent and severely UX-challenged such that no professional web site/app would really be able to use them in production. For these, in 2022, we still have no choice but to build custom implementations in order to meet usually expectations.
The only intuitive interface is the nipple. Everything else is learned. If the user has leaned how to use the native date picker on their browser, they know how to use the date picker on your website.
If you make them learn how to use a new date picker for your website, it's very unlikely they'll thank you for being able to transfer this unique knowledge to that one website of yours on the very unlikely chance they choose to switch browsers. I mean, who does that regularly?
And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. (Or a different OS!) That has the advantage of fixing the native date picker on every single website they go to. Except for the annoying websites which implement their own, where if the custom date picker doesn't work for them, they're fucked.
If someone's using a browser with an date picker you happen to dislike, that's their choice. Let them have it.
Our customers don't care about other browsers, Open Source software, or the nuance of native input fields. "Look, on AirBnb I can enter dates in a humane way, why is it so hard on your website?" - I just don't get away with recommending them to switch browsers.
Having accepted that premise, we can talk about the custom implementations: I would never recommend rolling your own, either. There are several widely used library for date pickers that users are accustomed to, are accessible, and miles ahead of the native controls. There is absolutely nothing wrong with sticking to those libraries until the vendors finally fix their mess.
If you ask a browser on Windows for a color picker, you get the old-and-busted one. Given the odd bifurcation in Windows UI since 8, I suspect date pickers are the same way, and the one the browser gives you won't actually match what other native apps are doing. So what happens if you decide to do the "right thing", is that you get a demonstrably worse user experience for your forms for the vast majority of people who do not know how to retheme native UI and have zero familiarity with the old Windows controls that browsers continue to throw at people.
[0] macOS has a native color picker that is apparently so good that someone reimplemented it for iPadOS.
[1] Adobe isn't even consistent among their own suite. The Photoshop color picker is entirely different from the Premiere or Animate ones, for example.
[2] I suspect the Paint 3D color picker may be a XAML default, but up until very recently the prospects of actually using XAML in most apps was very dim. More specifically, XAML used to be either exclusive to .NET/C#, or exclusive to Microsoft Store apps, neither of which were conducive to native software that need to live outside of an app container sandbox and be distributed through Steam.
Or, you know, if aesthetics or accessibility doesn't work with a native picker I might just use a third-party one instead of requiring my users to switch browsers and OSes.
Native date input have horrendously/hillariously bad implementations in all desktop browsers. I can't even begin to imagine thinking about using them for anything.
In the end, if it inserts a date, or a hex colour representation, then I am happy.
Although now that I think about it, there's a chance a date input would return `mm-dd-yyyy` or `dd-mm-yyyy` depending on locale. To have it return a unix datetime would probably be easier for everybody.
It’s not just a question of consistency: some of HTML UI elements are still in pre-alpha stage in modern browsers, almost completely broken, despite being part of the standard for many years. It’s a joke.
For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is.
There are projects that dedicate an unreasonable amount of resources to making these controls in JavaScript and show just how far you can get in JS. For example, https://headlessui.dev.
EDIT:
To directly address the "invisible buffer" thing, look at this control from Headless UI: https://headlessui.dev/react/listbox.
Open it, start typing, and notice the invisible buffer actually does work here.
In the state dropdown of the article I can type "New J" to highlight "New Jersey" and then press backspace + "Y" and it will highlight "New York". In the headless UI version if I try similar "To" to get "Tom…" but if I press backspace and "a" I don't get "Tanya…" I get "Arlene…"
I mean in addition to this keyboard UX, there's accessibility to consider; screen/braille readers, alternative input methods, etc.
As devs we don't decide, we get soem designs, like make a numeric input that looks like in this picture, make a select that can show a different icon for each option()like a language select with flag icons)), or make a font select that each item has it;s own font family.
Then you have stuff that are clasic things in normal GUI toolkits like accordions, tree views, very efficient grid/list views(I mean a widget where you can load 10K items and not have to implement your own smart loading or the lazy pagination way).
I did not done too much mobile but I remember there are some "tabbed/stacked views" , you can put your components in this views and would be efficiently loaded and unloaded when you moved from one view to other making things start faster and use less memory.
Not sure why the browser makers ignore this stuff, did they give up and we just have to use third party libraries for simple things like a good select and a working GridView?
However, I disagree with:
> The browser’s built-in controls are quite sufficient.
The problem is that browser components are good for simple forms but insufficient for other types of interaction.
A good example is select. Using the select tag is the best way to have a dropdown list that’s accessible and supports mobile. But, select doesn’t cover most of the cases that you need for a complex app.
Many of the WAI ARIA authoring examples (including the combobox patterns) are not covered by built in components. Interaction patterns like pop ups, dialogs, or lookup lists are quite common for an app… but hard to do in an accessible/cross-platform way.
Web browsers need to do something different to support accessible/usable apps. The idea of leaving all those things to WebComponents makes sense, but the result is reinventing the broken wheel on each app.
There are however a bunch of ARIA tags & best practices etc (https://w3c.github.io/aria-practices/) that exist to make popups and dialogs (and other things e.g. tree views or "email-inbox-style" "treegrids" etc) accessible (if implemented correctly).
I am conflicted about these - it is nice that there are ARIA tags for this, but it would also be nice if browsers "understood" aria tags and added some default behaviors (e.g. keyboard navigation). As it is, ARIA tags are essentially "pointless" to anyone who doesn't use an assistive technology, and so non-assitive-technology users nor developers benefit from using ARIA tags so they are often forgotten. If the browsers saw that there was an A11y-tree that matched a treeview or a treegrid, it would be really really nice if they applied some default common keyboard navigation implementation, rather than do nothing and leave it up to the developer to decide what keys do what on each and every site. .... Or on the other hand, is that too prescriptive and should we give developers and UX designers more leeway to design something better, rather than rely on browser-enforced defaults? I guess we are happy with browser defaults for basic inputs, but would we be for a treegrid?
Nevertheless, some of them are perfectly good solutions as-is and can serve as a good starting point.
I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by <header>, <main>, <footer>, etc. and explicit `role` attributes). I don't like the idea of browsers automatically creating interactive controls based on the presence of ARIA attributes, I'd rather there be new HTML elements, ones that document stylability much better than old ones did.
I'm interested in Open UI's [0] work, attempting to develop common web components, ones that can be useful in the short term and may serve as the basis for new HTML elements in the future. They're sort of documenting cow paths that HTML in the future can pave, similar to HTML5 elements being named based on common class names or useful additions to JavaScript having been based on features in libraries like jQuery (obviously without adopting jQuery's syntax).
And there even is a combobox in HTML5. It‘s an input with a list attribute.
Unfortunately, I recently heard that all the major browsers fail to resize the datalist text on zoom (my guess is it's rendered outside the DOM, like the browser's UI).
Bug report for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1756203
We use Angular so it's pretty easy to hide the custom control and have a plain control for accessibility. At least for checkbox and radio inputs, am I the only one that uses a hidden input to control the style of some div to make it look fancy like the design required?
disclaimer: 95% of my "modern" web frontend experience consists of non-professional goofing off in Svelte.
I don't understand why accessibility promoters endlessly bash developers, while the problem is that the edge between visual requirements and proper accessibility is extremely hard to dance, whereas it's mostly a non issue on proper platforms (eg. Cocoa/SwiftUI)
For example, <select> will give you a drop-down that lets you type to pick, but only the first letter, and only letters that directly correspond with a keycode. So you can't type "Uni" to get "United States of America"; you can't type "とうきょう" plus enter to get "東京", and so on. If you need to support IMEs or picking through large option sets, dropdowns are a bad option.
Of course, native UI developers know that you can use a combobox instead of a dropdown picker; but there's no <combobox> tag. You have to implement your own by attaching a bunch of div/event soup to an <input type=text>[0]. In this particular case, doing so will actually make the input more accessible, because keyboard users can just type the answer instead of having to press the first letter and hit down 200 times to get to the thing they want. It's also more internationalized, because you can use your IME to compose the characters you need to search through the list with.
[0] The select2 library will do this for you and it's my go-to if I need a combobox.
In the US I'm fairly sure there's only a requirement for accessibility if you're building something for the government. I'm certainly allowed to build a website that isn't accessible and not have it taken down.
Edit: Guess there's precedent to require some businesses to do it as well. Looks like I'm mostly wrong here.
> Making a custom form control with JavaScript is going to make life worse for a lot of people. Just don’t do it. The browser’s built-in controls are quite sufficient.
For my self-hosted minimal CRM (not really ready for anybody except me yet) [Aktenkoffer](https://github.com/svkurowski/aktenkoffer), I created a custom select that allows for filtering/searching of contacts when choosing sender/recipient for a given document. I don't use browser's select because:
1. There's a lot of contacts one has, and the list will become very long, a usecase for which select seems not to be the best fit, i.e. I don't want to load all the options always. 2. I cannot always remember how I formatted a contact name - e.g did I include the "Dr." at the beginning or not. Select quick-selection only works when I know exactly the sequence of characters I'm looking for (like the US state selection the author mentioned).
Obviously it has tons of feature gaps, I.e. pressing Esc does not close it (yet), up-and-down arrows don't work (yet), one cannot just type to go to one option.
Any suggestions, what to do in such a case? And how I can learn more about such approaches?
I love sourcehut, and its design and I would like to follow a closer to the browser, minimal UI but in practice it seems quite hard for me - harder than getting a custom select "half-right".
https://developer.mozilla.org/fr/docs/Web/HTML/Element/datal...
It's easy to say "use just the browser provided controls" until you actually have to build something that people need to use. What is expected today from even a simple form involves a lot of custom behavior that browsers do not provide, at what point is it "custom"? Advising against that will not help things become more usable nor accessible.
Instead of "just don't do it", I suggest to promote caring about usability and accessibility, and make people realize it should be evaluated for each individual situation and give practical information on how to do that.
Very basic practical advice; Use native elements where possible, if you run into their limitations preferably use an existing well build and maintained alternative that does implement all of the intricate details. Building something completely custom should be a last resort, if you do end up in that situation it's often beneficial to build it on top of something else.
(Having had some experience working on custom controls in a browser: it's the kind of project that will occupy a three-person team at a Fortune-500 full-time over multiple quarters to get right. Set your expectations accordingly.)
As I said in my original comment; I agree that where possible normal input elements are preferred, but they do not cover all cases. I guess it depends on what you consider custom, most of those use html form elements underneath, but they definitely require implementing the intricate details as described in the article.
I also don't think it's correct to say accessibility and usability come for free as long as you use plain html elements. You can build really horrible unusable forms with plain html elements, I've seen plenty (and I've probably build a few myself in the past haha).
My point is; "don't use X" and "don't do Y" posts are not helpful as they do not convey the point that both usability and accessibility require effort and consideration, and give a false sense of "if you don't do this all will be great" which is not the case.
However the downsides including breaking some OAuth authentication flows and sometimes you can't open fake links in new tabs when you want to.
However for me the consistency is still worth the minor breakagaes.
I had no idea that you could end with a drag to expand your selection by word or by line like that. That's really cool. (The author's using Linux, but it works on macOS too.)
Another example: default macOS dropdowns allow you to click and drag while holding the button to select something in one single gesture. Default <select> implementation in Chrome/Vivaldi also supports it. None of the custom JS ones support it.
The menu that opens from a <select> extends outside of the browser viewport which makes it easier to choose from long lists.
Anything that opens a custom popup menu, including a dropdown, can only close it when you click within the browser viewport, for obvious reasons. System popup menus (NSMenu I think?) are kinda system-modal in that you can close them by clicking anywhere on screen, which is more convenient.
(25 years later... still trying.)
There are sites like GitHub that slightly enhance a regular textarea (IIRC it is a textarea, haven't thought about it too much)
In practical terms for most developers, this holds true. Theoretically, you could replicate nearly the entire experience if you were patient and determined enough. Depending on the kind of product you are going for, it could make sense to invest in this capability.
Even accessibility can be addressed by doing things like dynamically inserting DOM nodes that screen readers can see. This is something I have played around with in my canvas/mjpeg/x264 rendering systems.
Practically, impossible, because browsers do not expose information about keyboard shortcuts respectively the associated semantic actions to the JS runtime environment, so a programmer looking to replicate has to make assumptions and hardcode keys.
I wonder about unbundling the different pieces of the browser. Sandboxing + safe-ish remotely-managed code is really cool. Zero-install apps is cool-ish, but comes with slow loading (try opening a new tab in gmail on my poor linux firefox).
But for UX things are tricky. The DOM is somehow simultaneously the best widgets library and a horrible widgets library. CSS isn't quite powerful enough, hence all the scroll jank tricks many sites are still doing, hence the difficulty of mixing classes and getting sane results.
I'd want a browser-like execution context, but with something more like JSX than the DOM, pluggable layout engines with the default one more like modern constraints languages than CSS, SPA-aware RPC primitives, and more attention paid to the customizability of text entry and scroll.
Electron IDEs are simultaneously great (so powerful and customizable) and really bad (built on the worst text entry tech you could pick).
the author is 99% right about the difficult of interacting with custom controls, possible exception of companies like shopify and stripe that have put massive investment into getting this stuff to work cross-platform.
That being said I would love to see a rich-text input with some default controls available.
In fact, the more bells and whistles I find on the requirements for individual form inputs, the more annoying it is the work on.
Simplicity is god for most of front-end.
However, people want more than just the 6 or so controls defined in the 1990s. Even w3c in their design system relies on a third-party autocomplete: https://design-system.w3.org/third-party-plugins/
The reason? Browser implementors rarely solve actual issues that are truly desired by most people. Because browser implementors are low-level C/C++ developers who rarely touch actual web development. So we get 41 distance units, and horrendously bad APIs like Service Workers and Custom Elements, and piles of things like Ambient light sensors [1]. But for all the hype and advertisement around web applications we don't really get things that actually make it easy to, you know, develop these applications. Google Docs is transitioning to canvas and Figma reimplemented half of the browser in WebGL not because web platform is so great.
There's now the https://open-ui.org project that collects common UI patterns that have been endlessly re-implemented across countless frameworks and libs. It will be another 40 years before any of them become a reality.
[1] Yes, it's a thing: https://chromestatus.com/feature/5298357018820608
Today, even apparently trivial widgets require ridiculous amounts of effort to attain a "natural" UX. To become so good you don't notice. That holy grail of being "invisible".
--
Epochs ago, I created custom controls for Win32. The one I was most proud of was a direct manipulation sundial picker for a raytracer. I obsessed over the details. Like being pixel perfect, both mouse and arrow keys (for fine grained increments), live updates between dial widget and text fields. Damn, I was proud of that control. I flushed and preened whenever a user complimented the effort.
Ages ago, I started using bootstrap-select. It's a nifty dropdown w/ type ahead (search). Modest, no big deal, right? Nope! That project received so many PRs, tweaks, fit & finish, finesse, and all around TLC. I was transfixed, fascinated. I haven't done UI for years, but remained subscribed to their project announcements, mostly out of awe and respect.
https://github.com/snapappointments/bootstrap-select
Observing the bootstrap-select project over time humbled me. I used to think I had some UX juice. Now I know that I'm just banging the rocks together.
Until you work on global webshop forms, where business/management wants hundreds of exceptions to the rules. Few examples: form input pre-fills, custom validation, auto-complete fields, fancy dropdowns, email/postcode checks that need to happen while filling in the form. I could go on. And it all should be manageable from some ancient CMS, of course.
Re-implementing built-in controls (the example of a <select> box is given in the OP) is obviously a very bad idea in almost all circumstances. Implementing a missing control is a much more difficult decision, and there are times when it can be a defensible choice to do so.
That’s before consider breaking all the password or address auto fills, screen readers, non-keyboard text entry.
Even if all you’re doing is “restyling” controls, how do you interact with people who have vision difficulties like colour blindness? You’re restyling overrides accessibility features that make controls visible.
Seriously, you don’t get to say “web apps should be just as capable as normal apps”, and also say “I should break basic app functionality”
The issue being that there’s many valid numbers that aren’t always parsable numbers as a human types them in (because of decimal or negative, etc.)
I'm glad you are sharing this, its good to be aware of and I might share this with my own product team in the future.
An extremely common use case at the last two companies I've worked at is a multi-select dropdown with autosuggest. Optionally, new items can be added to the list. Sometimes we needed to use ajax to populate the list, because you were searching 25,000+ items. We used this control in 10-15 different places, usually inside a spreadsheet cell. Which built-in controls should I use for this? I agree with the author that it is difficult to implement.
What do you recommend for a typeahead/autocomplete? In my case I’m using a third party API for results (geocoding), but even with a static list, the closest option is datalist, which is very limited
One that I would love would be some sort of drag and drop reorderable list, for example.
Besides, I usually build controls out of input primitives, not pure JS.
- egos