Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

drewdevault.com

Post reply on HN
Print view View original

11–20 of 227 posts

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

#11

Post by specialist »

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

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.

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

#12

Post by aarondf »

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.

EDIT:

To directly address the "invisible buffer" thing, look at this control from Headless UI: https://headlessui.dev/react/listbox.

Open it, start typing, and notice the invisible buffer actually does work here.

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

#13

Post by wffurr »

svkurowski wrote: post #5

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 ), I created a custom select that allows for filtering/searching of contacts when choo…

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

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

#14

Post by saint-loup »

svkurowski wrote: post #5

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 ), I created a custom select that allows for filtering/searching of contacts when choo…

Recent discovery: there's a native element, well supported except for Firefox@Android. It's a combo of and filtering (a combo box, to use the Windows parlance).

https://developer.mozilla.org/fr/docs/Web/HTML/Element/datal...

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

#15

Post by julianlam »

montroser wrote: post #9

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…

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.

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

#16

Post by nick238 »

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.

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

#17

Post by ryukoposting »

obpe wrote: post #10

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…

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.

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

#18

Post by Cthulhu_ »

aarondf wrote: post #12

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 . EDIT: To directly address the "invisible…

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.

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

#19

Post by Cthulhu_ »

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.

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

#20

Post by grenoire »

julianlam wrote: post #15
montroser wrote: post #9

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…

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.

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.
Post reply on HN