18 ms·

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

411 points by nitsky 5y ago

Cthulhu_ 5y ago
I prefer to use built-in controls as much as possible, but they have their flaws and missing features. One of my pet peeves / gripes is the half or broken implementation of new HTML5 input fields, like number or calendar inputs. I haven't found working them at all delightful.
gjvc 5y ago
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. (25 years later... still trying.)
- stereocodes 5y ago
  LOL
- rhdunn 5y ago
  The main issue here is that the listbox on a select control is not part of the DOM+CSS model. If it was then there wouldn't be as big a problem, as they could be styled and customized while still taking advantage of native functionality.
asddubs 5y ago
I wish more development went into form widgets. A big thing is also that they're accessible and responsive by default. One that I would love would be some sort of drag and drop reorderable list, for example.
rjknight 5y ago
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's web browsers. 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.
dmitriid 5y ago
Lots of people have been saying this for years, and accessibility voices are now being heard as well. It's extremely difficult to create a proper form control and remember all the usage patterns and all the edge cases. 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/ 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 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 https://chromestatus.com/feature/5298357018820608
svkurowski 5y ago
I was wondering about this, too. > 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 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".
- wffurr 5y ago
  There's not a great built-in combobox control, which is a shame. An input type=list element with a datalist comes close: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
- saint-loup 5y ago
  Recent discovery: there's a native <datalist> element, well supported except for Firefox@Android. It's a combo of <select> and filtering (a combo box, to use the Windows parlance). https://developer.mozilla.org/fr/docs/Web/HTML/Element/datalist https://developer.mozilla.org/fr/docs/Web/HTML/Element/datal...
  - theandrewbailey 5y ago
    The big downside is that datalist will only show exact matches of what you've put in. If you're doing a fuzzy search somewhere (or the user has a typo) and want to offer search suggestions, a native datalist doesn't work. I wish there was an attribute that forced all options to appear when filtering happens elsewhere and options are dynamic.
romaniv 5y ago
The best unit of isolation for web functionality is behaviors, not controls. Think of them as traits enabled and configured via attributes. I'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.
- bavell 5y ago
  Interesting, care to expand on behaviors vs controls?
mihaic 5y ago
I'd actually put the blame here on browsers, and how limited the default inputs are. 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.
- danielvaughn 5y ago
  What I think the web really needs is headless behavior via attributes.
  - easrng 5y ago
    Like onclick, onsubmit, etc? We already have those.
- egeozcan 5y ago
  The problem is not just styling, but usability, the API, and even accessibility too. Example, a multi-select, see https://jsfiddle.net/z0Ltxh47/1/ 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.
  - marcosdumay 5y ago
    To be fair, multi selection is a disaster on any platform. It is a hard concept that isn't completely solved by any of the standard GUI widgets.
    - egeozcan 5y ago
montroser 5y ago
For text inputs and select dropdowns, yes, we take them for granted because the simple case is simple -- but there really is so much 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. 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.
- julianlam 5y ago
  I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input? 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.
  - grenoire 5y ago
    The browser date pickers will always return YYYY-MM-DD to your server when they send a request. What's exposed to the user is usually localised. This is the behaviour you want.
  - p49k 5y ago
    > I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input? 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.
    - tentacleuno 5y ago
      > For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is. Could you shed some more light on this? I couldn't find anything from a cursory search. Looking at the W3Schools demo[0], it doesn't look too bad (other inputs set the bar really low). Is it not very friendly with styling? I hear that a lot when people talk about native browser controls. [0]: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_range https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_i...
obpe 5y ago
I have implemented many custom form controls. The reason is almost always because the design requires it. But other reasons can be to "improve" 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. 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?
- ryukoposting 5y ago
  In my (very limited) experience, the "hidden input" approach seems to be a reasonable approach. All the w3schools guides I've followed seem to do it that way. disclaimer: 95% of my "modern" web frontend experience consists of non-professional goofing off in Svelte.
  - enlyth 5y ago
    Sadly this is the "right" way, and as many other commenters in this thread have pointed out, the sad state of default browser components is to blame.
- grishka 5y ago
  If a designer wants me to do a custom control, I usually explain them why it's a bad idea and instead style the standard one.
- Klaster_1 5y ago
  The UI designers I had worked with do not have much experience working with the web platform as a user or developer, are not aware of capabilities default controls provide and almost never use the products they've designed. Additional exposure of UI compared to under-the-hood stuff begs for additional bikeshedding and micromanagement by people who understand this even less, like management. Maybe I never met good a designer or worked in a company with sane process.
aarondf 5y ago
A big part of the reason that JavaScript controls can't capture the nuance is because it takes a lot of work to capture the nuance. So teams justifiably implement the 90% use case and move on. 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 https://headlessui.dev. EDIT: To directly address the "invisible buffer" thing, look at this control from Headless UI: https://headlessui.dev/react/listbox https://headlessui.dev/react/listbox. Open it, start typing, and notice the invisible buffer actually does work here.
- Cthulhu_ 5y ago
  But... why not style the built-in controls? I mean in addition to this keyboard UX, there's accessibility to consider; screen/braille readers, alternative input methods, etc.
  - aarondf 5y ago
    I mean... you have to know that styling the default controls usually falls vastly short of what you're trying to do.
  - mhink 5y ago
    Because in a lot of cases, browsers don't expose the necessary APIs to do so. That being said, most component libraries I've seen that implement custom controls (which do expose APIs to allow styling) will make a point of adding all the necessary ARIA attributes to make controls properly accessible.
  - simion314 5y ago
    >But... why not style the built-in controls? 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?
specialist 5y ago
Emphatic agreement. 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 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.
nick238 5y ago
It's suuuper annoying when the type-to-pick-dropdown doesn't work. Mildly annoying for US states, I live in Illinois, so when it flashes "Idaho", "Louisiana", oh boy. These are usually the forms that then have a 'fake' dropdown for credit card expiration dates, so I can't type-to-pick the month/year either.
- grishka 5y ago
  Bonus points for when the month is the name of the month.
  - vsareto 5y ago
    Numbers vs. names for months is a legit casus belli
    - grishka 5y ago
      For credit cards though it's not — your card has the expiration month as a number on it. The form should take a number so you don't have to pause for several seconds to convert one to the other.
- Aachen 5y ago
  Spotify custom implemented this for their desktop client. You could right click on a song, open the submenu "add to playlist", and type a few characters. Idk why they bothered custom implementing that when a select list is a standard element no matter what framework they use, but I was happy. Then cometh the update and the feature be regressed. I now need to use the mouse for literally everything, including looking through this list with no discernable sorting (it's not alphabetical). Only spacebar for play/pause survived, all other keyboard controls seem gone or I can't guess them. Just use normal components. Save the effort, help the screen reader, please the power user. Please.
  - marcellus23 5y ago
    Ugh, Slack too. For ages they didn't have right-click menus anywhere. Then a while ago, they added right-click menus to channels, but of course they couldn't just use the native menus that every OS already has, so it's some HTML abomination that had to rewrite the wheel for handling things like lenient mouse movement (e.g. https://css-tricks.com/dropdown-menus-with-more-forgiving-mouse-movement-paths/ https://css-tricks.com/dropdown-menus-with-more-forgiving-mo...). Still doesn't support type-to-select, or god knows how many other accessibility and power user niceties.
eximius 5y ago
Can't or don't? Besides, I usually build controls out of input primitives, not pure JS.
peterjmag 5y ago
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 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.)
- reportgunner 5y ago
  Works on my Win10 machine too.
  - godot 5y ago
    This thread just makes me think of the thankless job of native frontend developers working on Linux/macOS/Windows OSes that made these nuances and behaviors work exactly to a specific standard. Ok, maybe not thankless in the case of Mac and Windows since they probably got paid. :) But yeah, I imagine all the edge cases aren't easy to handle.
grishka 5y ago
Yes. Very much this. 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.
- deleted 5y ago
  [deleted]
- frosted-flakes 5y ago
  Your last point is not true. You can set custom dropdowns to close on loss of focus, which will happen when clicking outside of the browser window. It makes debugging with the browaer tools a right pain in the neck, but it's totally possible.
  - grishka 5y ago
    Yes but then that click would still go through to wherever you clicked and activate some other window. System menus consume that click.
    - frosted-flakes 5y ago
      Not on Windows, with the exception of the Ribbon control in the File Explorer and Microsoft Office.
tuyiown 5y ago
The nuances should be exposed in a stylable, implementable and a documented API, with examples and guidelines. 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)
- robin_reala 5y ago
  But… that’s when as a developer you push back. Visual requirements don’t take the place of accessible components in countries where there’s a legal requirement for accessibility, which includes most of north america.
  - lucasmullens 5y ago
    > there’s a legal requirement for accessibility 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.
    - robin_reala 5y ago
      You’re required under the ADA to make “reasonable accommodations” for people with disabilities. This has been tested numerous times in court, most recently against Dominos: https://blog.ericgoldman.org/archives/2021/06/domino-pizzas-website-violated-the-americans-with-disabilities-act-ada-robes-v-dominos.htm https://blog.ericgoldman.org/archives/2021/06/domino-pizzas-...
    - gbear605 5y ago
      Judges have found that retail websites are subject to the ADA[1], and sites for things like utilities definitely are. Your personal website does not need to comply though, since it’s not considered a public space. [1]: https://myblindspot.org/2017/09/retail-websites-are-public-accommodations-subject-to-ada-judge-rules/ https://myblindspot.org/2017/09/retail-websites-are-public-a...
bradstewart 5y ago
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's infuriating.
diegof79 5y ago
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. 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.
- nedt 5y ago
  Oh the combobox element in the WAI ARIA is interesting. On mobile the dropdown can‘t be scrolled without scrolling the page (and the user losing where they were in the form). Also the tap targets are smaller. And there even is a combobox in HTML5. It‘s an input with a list attribute.
  - extra88 5y ago
    Do you mean <datalist>? It doesn't meet all use cases (especially if what needs to be listed requires dynamic updating) but browser support slowly has gotten better. 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1756203
    - bob1029 5y ago
      Datalist has some unfortunate UX quirks in my experience. Trying to view the list of available items after you have already selected one is not possible on the browsers I used this week. A select will allow you to view the list regardless of the current value.
woudsma 5y ago
> The browser’s built-in controls are quite sufficient. 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.
msoad 5y ago
It's such a blanket statement to say "you can't". Those controls themselves are coded up mostly using JavaScript so it is defiantly possible. It just requires a lot of work. 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 https://react-spectrum.adobe.com/react-spectrum/index.html
- lkxijlewlf 5y ago
  > ... defiantly possible In a lot of cases, yes.
- lol768 5y ago
  > supports all of those nuances mentioned here for all of their controls and allow for styling and customization I don't believe it. Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html 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.
padseeker 5y ago
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. 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.
codeptualize 5y ago
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. 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.
- shadowgovt 5y ago
  Agreed. I think about custom controls like I think about cryptography libraries: most hackers aren't specialized enough to have thought through all the corner cases and unless you want that to be your specialty, you're taking on a lot of risk of blowing your own leg off (metaphorically speaking) trying to hack out a solution instead of using something (ideally) well-maintained and with some history behind it. (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.)
- withinboredom 5y ago
  I’ve used browser controls for the last 20 years on any form I’ve ever implemented. These days you get validation errors, accessibility, and so much more for free — even if JavaScript is turned off. I can’t think of a reason you’d ever want to use a custom control on a form.
  - codeptualize 5y ago
karaterobot 5y ago
> 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. 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.
- deleted 5y ago
  [deleted]
jaywalk 5y ago
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're going to look how they look.
- vsareto 5y ago
  Me wishing every UI/UX person understood this. 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.
LinAGKar 5y ago
Same with links, for example when someone makes a JavaScript link and breaks the middle click to open in new tab
- bandie91 5y ago
  many +1 and add target=_blank to the list.
  - LinAGKar 5y ago
    Yes, definitely
  - kevincox 5y ago
    In Firefox there is an option to override this in about:config so that all links open in the same tab. 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.
khepin 5y ago
Worst of those I encounter regularly is US sites trying to constrain your input to numbers only on certain fields. Not "letting you input anything and marking it invalid if you put something other than a number", 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'd be smart...
- fuzzy2 5y ago
  Oh yeah I had that recently in a project (IE support required, so no type=number). When you try this, you will eventually find that you use so many keys during normal operation that a whitelist just isn't feasible. Left, right, tab, Home, End, Ctrl+C/V, Shift+Ins, …
  - account42 5y ago
    Throwing away keys is never the right thing to do anyway. If the user typed 5y8 you don't know if they meant 58 or if the y was meant to be a 6 or 7 so the best thing to do is to have the field contain the full user input and higlight the input as invalid rather than silently guessing what the user meant.
    - Sammi 5y ago
      Validate, don't parse ;p
scelerat 5y ago
"no, but we want our customers to have an immersive brand experience" - egos
stereocodes 5y ago
As I type into a regular textarea on this site I'm wondering where these textarea replacements on websites are? I'd love for a few examples of this happening. "Many" JS programmers recreate the textarea? Show me.
- strager 5y ago
  Facebook, Twitter, Gmail, Discord
- kevincox 5y ago
  It depends exactly what you mean by textarea. If you need rich text you need something custom. (Although you can use contenteditable as a base) There are sites like GitHub that slightly enhance a regular textarea (IIRC it is a textarea, haven't thought about it too much)
timwis 5y ago
> The browser’s built-in controls are quite sufficient. 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
danschumann 5y ago
"The most efficient system is no system" -Elon Musk
blacklion 5y ago
It is why I hate Electron apps which disguise themselves as native ones.
olliej 5y ago
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. 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”
awinter-py 5y ago
google docs reimplemented their whole UX in canvas, and this is a giant company that controls browser standards as much as anyone does. can't think of a louder way to admit defeat re advanced text entry on the web 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.
- kevincox 5y ago
  To be fair Google Docs is a bit different here. To a large extent their goal is to display what is going to be printed (this is changing a bit with the new pageless mode and things like checkboxes but still is the core). So doing all of the rendering themselves actually makes sense. That being said I would love to see a rich-text input with some default controls available.
bob1029 5y ago
> 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. 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.
- bmn__ 5y ago
  > Theoretically, you could replicate nearly the entire experience if you were patient and determined enough. 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.
Waterluvian 5y ago
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. 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.)
- deleted 5y ago
  [deleted]
astrea 5y ago
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.
ycui1986 5y ago
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.

411 points by nitsky 5y ago

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

gjvc 5y ago

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. (25 years later... still trying.)

stereocodes 5y ago
LOL
rhdunn 5y ago
The main issue here is that the listbox on a select control is not part of the DOM+CSS model. If it was then there wouldn't be as big a problem, as they could be styled and customized while still taking advantage of native functionality.

asddubs 5y ago

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

rjknight 5y ago

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's web browsers. 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.

dmitriid 5y ago

Lots of people have been saying this for years, and accessibility voices are now being heard as well. It's extremely difficult to create a proper form control and remember all the usage patterns and all the edge cases. 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/ 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 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 https://chromestatus.com/feature/5298357018820608

svkurowski 5y ago

I was wondering about this, too. > 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 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".

wffurr 5y ago
There's not a great built-in combobox control, which is a shame. An input type=list element with a datalist comes close: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...
saint-loup 5y ago
Recent discovery: there's a native <datalist> element, well supported except for Firefox@Android. It's a combo of <select> and filtering (a combo box, to use the Windows parlance). https://developer.mozilla.org/fr/docs/Web/HTML/Element/datalist https://developer.mozilla.org/fr/docs/Web/HTML/Element/datal...
- theandrewbailey 5y ago
  The big downside is that datalist will only show exact matches of what you've put in. If you're doing a fuzzy search somewhere (or the user has a typo) and want to offer search suggestions, a native datalist doesn't work. I wish there was an attribute that forced all options to appear when filtering happens elsewhere and options are dynamic.

romaniv 5y ago

The best unit of isolation for web functionality is behaviors, not controls. Think of them as traits enabled and configured via attributes. I'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.

bavell 5y ago
Interesting, care to expand on behaviors vs controls?

mihaic 5y ago

I'd actually put the blame here on browsers, and how limited the default inputs are. 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.

danielvaughn 5y ago
What I think the web really needs is headless behavior via attributes.
- easrng 5y ago
  Like onclick, onsubmit, etc? We already have those.
egeozcan 5y ago
The problem is not just styling, but usability, the API, and even accessibility too. Example, a multi-select, see https://jsfiddle.net/z0Ltxh47/1/ 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.
- marcosdumay 5y ago
  To be fair, multi selection is a disaster on any platform. It is a hard concept that isn't completely solved by any of the standard GUI widgets.
  - egeozcan 5y ago

montroser 5y ago

For text inputs and select dropdowns, yes, we take them for granted because the simple case is simple -- but there really is so much 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. 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.

julianlam 5y ago
I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input? 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.
- grenoire 5y ago
  The browser date pickers will always return YYYY-MM-DD to your server when they send a request. What's exposed to the user is usually localised. This is the behaviour you want.
- p49k 5y ago
  > I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input? 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.
  - tentacleuno 5y ago
    > For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is. Could you shed some more light on this? I couldn't find anything from a cursory search. Looking at the W3Schools demo[0], it doesn't look too bad (other inputs set the bar really low). Is it not very friendly with styling? I hear that a lot when people talk about native browser controls. [0]: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_range https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_i...

obpe 5y ago

I have implemented many custom form controls. The reason is almost always because the design requires it. But other reasons can be to "improve" 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. 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?

ryukoposting 5y ago
In my (very limited) experience, the "hidden input" approach seems to be a reasonable approach. All the w3schools guides I've followed seem to do it that way. disclaimer: 95% of my "modern" web frontend experience consists of non-professional goofing off in Svelte.
- enlyth 5y ago
  Sadly this is the "right" way, and as many other commenters in this thread have pointed out, the sad state of default browser components is to blame.
grishka 5y ago
If a designer wants me to do a custom control, I usually explain them why it's a bad idea and instead style the standard one.
Klaster_1 5y ago
The UI designers I had worked with do not have much experience working with the web platform as a user or developer, are not aware of capabilities default controls provide and almost never use the products they've designed. Additional exposure of UI compared to under-the-hood stuff begs for additional bikeshedding and micromanagement by people who understand this even less, like management. Maybe I never met good a designer or worked in a company with sane process.

aarondf 5y ago

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

Cthulhu_ 5y ago
But... why not style the built-in controls? I mean in addition to this keyboard UX, there's accessibility to consider; screen/braille readers, alternative input methods, etc.
- aarondf 5y ago
  I mean... you have to know that styling the default controls usually falls vastly short of what you're trying to do.
- mhink 5y ago
  Because in a lot of cases, browsers don't expose the necessary APIs to do so. That being said, most component libraries I've seen that implement custom controls (which do expose APIs to allow styling) will make a point of adding all the necessary ARIA attributes to make controls properly accessible.
- simion314 5y ago
  >But... why not style the built-in controls? 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?

specialist 5y ago

Emphatic agreement. 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 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.

nick238 5y ago

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

grishka 5y ago
Bonus points for when the month is the name of the month.
- vsareto 5y ago
  Numbers vs. names for months is a legit casus belli
  - grishka 5y ago
    For credit cards though it's not — your card has the expiration month as a number on it. The form should take a number so you don't have to pause for several seconds to convert one to the other.
Aachen 5y ago
Spotify custom implemented this for their desktop client. You could right click on a song, open the submenu "add to playlist", and type a few characters. Idk why they bothered custom implementing that when a select list is a standard element no matter what framework they use, but I was happy. Then cometh the update and the feature be regressed. I now need to use the mouse for literally everything, including looking through this list with no discernable sorting (it's not alphabetical). Only spacebar for play/pause survived, all other keyboard controls seem gone or I can't guess them. Just use normal components. Save the effort, help the screen reader, please the power user. Please.
- marcellus23 5y ago
  Ugh, Slack too. For ages they didn't have right-click menus anywhere. Then a while ago, they added right-click menus to channels, but of course they couldn't just use the native menus that every OS already has, so it's some HTML abomination that had to rewrite the wheel for handling things like lenient mouse movement (e.g. https://css-tricks.com/dropdown-menus-with-more-forgiving-mouse-movement-paths/ https://css-tricks.com/dropdown-menus-with-more-forgiving-mo...). Still doesn't support type-to-select, or god knows how many other accessibility and power user niceties.

eximius 5y ago

Can't or don't? Besides, I usually build controls out of input primitives, not pure JS.

peterjmag 5y ago

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 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.)

reportgunner 5y ago
Works on my Win10 machine too.
- godot 5y ago
  This thread just makes me think of the thankless job of native frontend developers working on Linux/macOS/Windows OSes that made these nuances and behaviors work exactly to a specific standard. Ok, maybe not thankless in the case of Mac and Windows since they probably got paid. :) But yeah, I imagine all the edge cases aren't easy to handle.

grishka 5y ago

Yes. Very much this. 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.

deleted 5y ago
[deleted]
frosted-flakes 5y ago
Your last point is not true. You can set custom dropdowns to close on loss of focus, which will happen when clicking outside of the browser window. It makes debugging with the browaer tools a right pain in the neck, but it's totally possible.
- grishka 5y ago
  Yes but then that click would still go through to wherever you clicked and activate some other window. System menus consume that click.
  - frosted-flakes 5y ago
    Not on Windows, with the exception of the Ribbon control in the File Explorer and Microsoft Office.

tuyiown 5y ago

The nuances should be exposed in a stylable, implementable and a documented API, with examples and guidelines. 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)

robin_reala 5y ago
But… that’s when as a developer you push back. Visual requirements don’t take the place of accessible components in countries where there’s a legal requirement for accessibility, which includes most of north america.
- lucasmullens 5y ago
  > there’s a legal requirement for accessibility 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.
  - robin_reala 5y ago
    You’re required under the ADA to make “reasonable accommodations” for people with disabilities. This has been tested numerous times in court, most recently against Dominos: https://blog.ericgoldman.org/archives/2021/06/domino-pizzas-website-violated-the-americans-with-disabilities-act-ada-robes-v-dominos.htm https://blog.ericgoldman.org/archives/2021/06/domino-pizzas-...
  - gbear605 5y ago
    Judges have found that retail websites are subject to the ADA[1], and sites for things like utilities definitely are. Your personal website does not need to comply though, since it’s not considered a public space. [1]: https://myblindspot.org/2017/09/retail-websites-are-public-accommodations-subject-to-ada-judge-rules/ https://myblindspot.org/2017/09/retail-websites-are-public-a...

bradstewart 5y ago

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's infuriating.

diegof79 5y ago

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. 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.

nedt 5y ago
Oh the combobox element in the WAI ARIA is interesting. On mobile the dropdown can‘t be scrolled without scrolling the page (and the user losing where they were in the form). Also the tap targets are smaller. And there even is a combobox in HTML5. It‘s an input with a list attribute.
- extra88 5y ago
  Do you mean <datalist>? It doesn't meet all use cases (especially if what needs to be listed requires dynamic updating) but browser support slowly has gotten better. 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 https://bugzilla.mozilla.org/show_bug.cgi?id=1756203
  - bob1029 5y ago
    Datalist has some unfortunate UX quirks in my experience. Trying to view the list of available items after you have already selected one is not possible on the browsers I used this week. A select will allow you to view the list regardless of the current value.

woudsma 5y ago

> The browser’s built-in controls are quite sufficient. 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.

msoad 5y ago

It's such a blanket statement to say "you can't". Those controls themselves are coded up mostly using JavaScript so it is defiantly possible. It just requires a lot of work. 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 https://react-spectrum.adobe.com/react-spectrum/index.html

lkxijlewlf 5y ago
> ... defiantly possible In a lot of cases, yes.
lol768 5y ago
> supports all of those nuances mentioned here for all of their controls and allow for styling and customization I don't believe it. Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html 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.

padseeker 5y ago

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. 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.

codeptualize 5y ago

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. 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.

shadowgovt 5y ago
Agreed. I think about custom controls like I think about cryptography libraries: most hackers aren't specialized enough to have thought through all the corner cases and unless you want that to be your specialty, you're taking on a lot of risk of blowing your own leg off (metaphorically speaking) trying to hack out a solution instead of using something (ideally) well-maintained and with some history behind it. (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.)
withinboredom 5y ago
I’ve used browser controls for the last 20 years on any form I’ve ever implemented. These days you get validation errors, accessibility, and so much more for free — even if JavaScript is turned off. I can’t think of a reason you’d ever want to use a custom control on a form.
- codeptualize 5y ago

karaterobot 5y ago

> 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. 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.

deleted 5y ago
[deleted]

jaywalk 5y ago

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're going to look how they look.

vsareto 5y ago
Me wishing every UI/UX person understood this. 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.

LinAGKar 5y ago

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

bandie91 5y ago
many +1 and add target=_blank to the list.
- LinAGKar 5y ago
  Yes, definitely
- kevincox 5y ago
  In Firefox there is an option to override this in about:config so that all links open in the same tab. 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.

khepin 5y ago

Worst of those I encounter regularly is US sites trying to constrain your input to numbers only on certain fields. Not "letting you input anything and marking it invalid if you put something other than a number", 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'd be smart...

fuzzy2 5y ago
Oh yeah I had that recently in a project (IE support required, so no type=number). When you try this, you will eventually find that you use so many keys during normal operation that a whitelist just isn't feasible. Left, right, tab, Home, End, Ctrl+C/V, Shift+Ins, …
- account42 5y ago
  Throwing away keys is never the right thing to do anyway. If the user typed 5y8 you don't know if they meant 58 or if the y was meant to be a 6 or 7 so the best thing to do is to have the field contain the full user input and higlight the input as invalid rather than silently guessing what the user meant.
  - Sammi 5y ago
    Validate, don't parse ;p

scelerat 5y ago

"no, but we want our customers to have an immersive brand experience" - egos

stereocodes 5y ago

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

strager 5y ago
Facebook, Twitter, Gmail, Discord
kevincox 5y ago
It depends exactly what you mean by textarea. If you need rich text you need something custom. (Although you can use contenteditable as a base) There are sites like GitHub that slightly enhance a regular textarea (IIRC it is a textarea, haven't thought about it too much)

timwis 5y ago

> The browser’s built-in controls are quite sufficient. 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

danschumann 5y ago

"The most efficient system is no system" -Elon Musk

blacklion 5y ago

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

olliej 5y ago

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. 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”

awinter-py 5y ago

google docs reimplemented their whole UX in canvas, and this is a giant company that controls browser standards as much as anyone does. can't think of a louder way to admit defeat re advanced text entry on the web 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.

kevincox 5y ago
To be fair Google Docs is a bit different here. To a large extent their goal is to display what is going to be printed (this is changing a bit with the new pageless mode and things like checkboxes but still is the core). So doing all of the rendering themselves actually makes sense. That being said I would love to see a rich-text input with some default controls available.

bob1029 5y ago

> 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. 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.

bmn__ 5y ago
> Theoretically, you could replicate nearly the entire experience if you were patient and determined enough. 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.

Waterluvian 5y ago

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. 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.)

deleted 5y ago
[deleted]

astrea 5y ago

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.

ycui1986 5y ago

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.