Custom JavaScript controls can't capture the nuance of form fields (2021)

I&#x27;d actually put the blame here on browsers, and how limited the default inputs are.<p>There are too many needlessly reimplemented components, but anyone that has ever needed to style a &lt;select&gt; to make it look in line with any modern design quickly reached desperation.<p>I&#x27;d love to be able to use standard components everywhere, but most of my users care if my website looks like it&#x27;s from 2004.

Worst of those I encounter regularly is US sites trying to constrain your input to numbers only on certain fields. Not &quot;letting you input anything and marking it invalid if you put something other than a number&quot;, but listening to which key is pressed to allow the typing or not. On French keyboards, typing a number requires the use of the SHIFT key. So I regularly need to change my keyboard layout just to type a couple numbers in a form field because someone thought they&#x27;d be smart...

I agree with the author that custom components don’t capture all the interaction details. Many times they are not accessible or cannot implement cross-platform input well.<p>However, I disagree with:<p>&gt; The browser’s built-in controls are quite sufficient.<p>The problem is that browser components are good for simple forms but insufficient for other types of interaction.<p>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.<p>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&#x2F;cross-platform way.<p>Web browsers need to do something different to support accessible&#x2F;usable apps. The idea of leaving all those things to WebComponents makes sense, but the result is reinventing the broken wheel on each app.

It&#x27;s suuuper annoying when the type-to-pick-dropdown doesn&#x27;t work. Mildly annoying for US states, I live in Illinois, so when it flashes &quot;Idaho&quot;, &quot;Louisiana&quot;, oh boy. These are usually the forms that then have a &#x27;fake&#x27; dropdown for credit card expiration dates, so I can&#x27;t type-to-pick the month&#x2F;year either.

For text inputs and select dropdowns, yes, we take them for granted because the simple case is simple -- but there really is <i>so much</i> complexity in keyboard navigation and interaction. Reaching parity in a JS implementation would be a serious undertaking and would usually not be the right thing to do.<p>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&#x2F;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.

A big part of the reason that JavaScript controls can&#x27;t capture the nuance is because it takes <i>a lot of work</i> to capture the nuance. So teams justifiably implement the 90% use case and move on.<p>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, <a href="https:&#x2F;&#x2F;headlessui.dev" rel="nofollow">https:&#x2F;&#x2F;headlessui.dev</a>.<p>EDIT:<p>To directly address the &quot;invisible buffer&quot; thing, look at this control from Headless UI: <a href="https:&#x2F;&#x2F;headlessui.dev&#x2F;react&#x2F;listbox" rel="nofollow">https:&#x2F;&#x2F;headlessui.dev&#x2F;react&#x2F;listbox</a>.<p>Open it, start typing, and notice the invisible buffer actually does work here.

I have implemented many custom form controls. The reason is almost always because the design requires it. But other reasons can be to &quot;improve&quot; the control; for the select box to make the invisible edit buffer visible. I appreciate this is not the way but it is also pretty annoying how limited the styling, and customization, of form controls is.<p>We use Angular so it&#x27;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?

It&#x27;s such a blanket statement to say &quot;you can&#x27;t&quot;. Those controls themselves are coded up mostly using JavaScript so it is defiantly possible. It just requires a lot of work.<p>The most accessible component library that I&#x27;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.<p>[1] <a href="https:&#x2F;&#x2F;react-spectrum.adobe.com&#x2F;react-spectrum&#x2F;index.html" rel="nofollow">https:&#x2F;&#x2F;react-spectrum.adobe.com&#x2F;react-spectrum&#x2F;index.html</a>

<i>Double clicking selects a word, and triple-clicking selects the whole line. If I double- or triple-click-and-hold, I can drag the mouse to expand the selection word-wise or line-wise, not just character-wise. This works with the paragraphs of text in the body of this blog post, too.</i><p>I had no idea that you could end with a drag to expand your selection by word or by line like that. That&#x27;s really cool. (The author&#x27;s using Linux, but it works on macOS too.)

Lots of people have been saying this for years, and accessibility voices are now being heard as well. It&#x27;s extremely difficult to create a proper form control and remember all the usage patterns and all the edge cases.<p>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: <a href="https:&#x2F;&#x2F;design-system.w3.org&#x2F;third-party-plugins&#x2F;" rel="nofollow">https:&#x2F;&#x2F;design-system.w3.org&#x2F;third-party-plugins&#x2F;</a><p>The reason? Browser implementors rarely solve actual issues that are truly desired by most people. Because browser implementors are low-level C&#x2F;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 <i>applications</i> we don&#x27;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.<p>There&#x27;s now the <a href="https:&#x2F;&#x2F;open-ui.org" rel="nofollow">https:&#x2F;&#x2F;open-ui.org</a> 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.<p>[1] Yes, it&#x27;s a thing: <a href="https:&#x2F;&#x2F;chromestatus.com&#x2F;feature&#x2F;5298357018820608" rel="nofollow">https:&#x2F;&#x2F;chromestatus.com&#x2F;feature&#x2F;5298357018820608</a>

The nuances should be exposed in a stylable, implementable and a documented API, with examples and guidelines.<p>I don&#x27;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&#x27;s mostly a non issue on proper platforms (eg. Cocoa&#x2F;SwiftUI)

I was wondering about this, too.<p>&gt; 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.<p>For my self-hosted minimal CRM (not really ready for anybody except me yet) [Aktenkoffer](<a href="https:&#x2F;&#x2F;github.com&#x2F;svkurowski&#x2F;aktenkoffer" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;svkurowski&#x2F;aktenkoffer</a>), I created a custom select that allows for filtering&#x2F;searching of contacts when choosing sender&#x2F;recipient for a given document. I don&#x27;t use browser&#x27;s select because:<p>1. There&#x27;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&#x27;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 &quot;Dr.&quot; at the beginning or not. Select quick-selection only works when I know exactly the sequence of characters I&#x27;m looking for (like the US state selection the author mentioned).<p>Obviously it has tons of feature gaps, I.e. pressing Esc does not close it (yet), up-and-down arrows don&#x27;t work (yet), one cannot just type to go to one option.<p>Any suggestions, what to do in such a case? And how I can learn more about such approaches?<p>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 &quot;half-right&quot;.

Emphatic agreement.<p>Today, even apparently trivial widgets require ridiculous amounts of effort to attain a &quot;natural&quot; UX. To become so good you don&#x27;t notice. That holy grail of being &quot;invisible&quot;.<p>--<p>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.<p>Ages ago, I started using bootstrap-select. It&#x27;s a nifty dropdown w&#x2F; type ahead (search). Modest, no big deal, right? Nope! That project received so many PRs, tweaks, fit &amp; finish, finesse, and all around TLC. I was transfixed, fascinated. I haven&#x27;t done UI for years, but remained subscribed to their project announcements, mostly out of awe and respect.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;snapappointments&#x2F;bootstrap-select" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;snapappointments&#x2F;bootstrap-select</a><p>Observing the bootstrap-select project over time humbled me. I used to think I had some UX juice. Now I know that I&#x27;m just banging the rocks together.

I prefer to use built-in controls as much as possible, but they have their flaws and missing features. One of my pet peeves &#x2F; gripes is the half or broken implementation of new HTML5 input fields, like number or calendar inputs. I haven&#x27;t found working them at all delightful.

&gt; The browser’s built-in controls are quite sufficient.<p>Until you work on global webshop forms, where business&#x2F;management wants hundreds of exceptions to the rules. Few examples: form input pre-fills, custom validation, auto-complete fields, fancy dropdowns, email&#x2F;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.

Yes. Very much this.<p>Another example: default macOS dropdowns allow you to click and drag while holding the button to select something in one single gesture. Default &lt;select&gt; implementation in Chrome&#x2F;Vivaldi also supports it. None of the custom JS ones support it.<p>The menu that opens from a &lt;select&gt; extends outside of the browser viewport which makes it easier to choose from long lists.<p>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.

This is true, but the set of custom controls is quite small. Controls that were built-in to, say, Visual Basic 4.0 in 1995 are not present in today&#x27;s web browsers.<p>Re-implementing built-in controls (the example of a &lt;select&gt; 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.

This is not helpful imo. Although it correctly identifies a problem of badly implemented controls. The explanation and solution show a lack of knowledge and understanding about the topic and current situation.<p>It&#x27;s easy to say &quot;use just the browser provided controls&quot; 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 &quot;custom&quot;? Advising against that will not help things become more usable nor accessible.<p>Instead of &quot;just don&#x27;t do it&quot;, 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.<p>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&#x27;s often beneficial to build it on top of something else.

By far the most annoying thing to me (as a user who does not rely on accessibility features) is how few JS-built forms support TABing through the fields, in the correct order. It&#x27;s infuriating.

I think a real problem here is that people (especially English only) do not understand the actual complexity of most standard input controls. They really think it’s just “type letters”. The number of times I’ve seen people showing their “fully functional” editors that flat out do not work with IM[E]s, do not handle basic keyboard controls, do not handle pasting or search propErly never ceases to amaze me.<p>That’s before consider breaking all the password or address auto fills, screen readers, non-keyboard text entry.<p>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.<p>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”

Number inputs have given me the most pain. The trick is that you need to manage two states: the current string state of the input and the most recent valid number state or null or NaN or whatever you want.<p>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.)

Same with links, for example when someone makes a JavaScript link and breaks the middle click to open in new tab

The sooner we stop attempting to fool each other that DOM + CSS is a suitable model for composing user interfaces which were previously implemented as native apps, the sooner we will get past the web era and on to something better.<p>(25 years later... still trying.)

As I type into a regular textarea on this site I&#x27;m wondering where these textarea replacements on websites are? I&#x27;d love for a few examples of this happening. &quot;Many&quot; JS programmers recreate the textarea? Show me.

This is an interesting comment but also an edge case. I build custom components all the time, such as a combo box that allows a user to select a list of options but also allows the user to type in a fragment and the options will be displayed filtered based on the text fragment typed. I would imagine your use case is a nightmare, but the average dev team and product manager is probably myopic and anglo-centric so they are more worried about the average latin language based user as opposed to your use case.<p>I&#x27;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.

&gt; 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.<p>An extremely common use case at the last two companies I&#x27;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.

&gt; You cannot capture all of this nuance in a home-grown form control, or even anything close to it, but many JavaScript programmers do it anyway.<p>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.<p>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&#x2F;mjpeg&#x2F;x264 rendering systems.

Digikey changed their website last year and the specific nuance the article mentioned is not being implemented. Made my life a bit more miserable when purchasing electronics components.

google docs reimplemented their whole UX in canvas, and this is a giant company that <i>controls browser standards</i> as much as anyone does. can&#x27;t think of a louder way to admit defeat re advanced text entry on the web<p>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).<p>But for UX things are tricky. The DOM is somehow simultaneously the best widgets library and a horrible widgets library. CSS isn&#x27;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.<p>I&#x27;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.<p>Electron IDEs are simultaneously great (so powerful and customizable) and really bad (built on the worst text entry tech you could pick).<p>the author is 99% right about the difficult of interacting with custom controls, possible exception of companies like shopify and stripe that have put <i>massive</i> investment into getting this stuff to work cross-platform.

The best unit of isolation for web functionality is behaviors, not controls. Think of them as traits enabled and configured via attributes. I&#x27;ve used such things on many different projects with very good results. The main advantage is that if you design them properly it is trivial to extend built-in functionality without reinventing the flat tire.

Selects are the absolute worst when it comes to customization. I totally understand it from a design perspective, but I will always push back on it aside from customizing the box itself. The actual dropdown options? Sorry, they&#x27;re going to look how they look.

&gt; The browser’s built-in controls are quite sufficient.<p>What do you recommend for a typeahead&#x2F;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

Calendar date selectors and phone number fields that try to automagically format my phone number into some predefined format (usually (xxx)-xxx-xxxx) and insert characters are the bane of my existence.

It is why I hate Electron apps which disguise themselves as native ones.

I wish more development went into form widgets. A big thing is also that they&#x27;re accessible and responsive by default.<p>One that I would love would be some sort of drag and drop reorderable list, for example.

Can&#x27;t or don&#x27;t?<p>Besides, I usually build controls out of input primitives, not pure JS.

&quot;no, but we want our customers to have an immersive brand experience&quot;<p>- egos

&quot;The most efficient system is no system&quot; -Elon Musk