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

31–40 of 227 posts

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

#31

Post by robin_reala »

tuyiown wrote: post #26

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)

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.

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

#32

Post by grishka »

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…

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.

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

#34

Post by grishka »

nick238 wrote: post #16

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.

Bonus points for when the month is the name of the month.

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

#35

Post by stuartloxton »

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…

The "invisible buffer" doesn't match OS X functionality (with Firefox if it matters).

In the state dropdown of the article I can type "New J" to highlight "New Jersey" and then press backspace + "Y" and it will highlight "New York". In the headless UI version if I try similar "To" to get "Tom…" but if I press backspace and "a" I don't get "Tanya…" I get "Arlene…"

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

#36

Post by Aachen »

nick238 wrote: post #16

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.

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.

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

#37

Post by egeozcan »

mihaic wrote: post #7

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

The problem is not just styling, but usability, the API, and even accessibility too.

Example, a multi-select, see https://jsfiddle.net/z0Ltxh47/1/ :

Usability is bad because I can't select multiple non-consecutive items by using just my mouse. It's very narrow by default, and doesn't allow me to resize.

API: Your typical HTMLInputElement.value doesn't give me all the selected values. I need to map the .selectedValues to their values, or innerText if no value exist. Horrific.

Accesibility: At least in Firefox, using ctrl+arrows to be able to focus on elements to select them do not render any focus targets. In Chrome, the contrast is not there.

Don't even get me even started with the date/time-picker.

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

#38

Post by diegof79 »

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.

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

#39

Post by woudsma »

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

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

#40

Post by dmitriid »

Karellen wrote: post #29
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…

A native date input might be inconsistent between different browsers, or different OSs, but it will be consistent with the native date input on every single other website the user goes to. If they're lucky, it will be consistent with the date input field on every other application on their OS. The only intuitive interface is the nipple. Everything else is learned. If the user has leaned how to use the native date pic…

> And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser.

Or, you know, if aesthetics or accessibility doesn't work with a native picker I might just use a third-party one instead of requiring my users to switch browsers and OSes.

Native date input have horrendously/hillariously bad implementations in all desktop browsers. I can't even begin to imagine thinking about using them for anything.

Post reply on HN