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

141–150 of 227 posts

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

#141

Post by egeozcan »

nine_k wrote: post #137
crooked-v wrote: post #132

Earlier quoted context omitted.

Now make that a set of 200 checkboxes and see how practical it is compared to one combobox-style multi-select input.

200 checkboxes make about as much sense as a 200-item dropdown. Neither is manageable. The multi-select dropdown is additionally hard to check for the selections made. An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative. Another, larger alternative is the typical two-lists control, with selected items moved from the source list to the target list…

> 200 checkboxes make about as much sense as a 200-item dropdown. Neither is manageable.

Multi-select is okay there, apart from the problems I mentioned above: https://jsfiddle.net/z0Ltxh47/2/ . I can navigate to i19 with a few key strokes. Only if it were then possible to easily select a1...

> An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative

And we are back at implementing our custom controls again.

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

#142

Post by egeozcan »

earthboundkid wrote: post #138
crooked-v wrote: post #132

Earlier quoted context omitted.

Now make that a set of 200 checkboxes and see how practical it is compared to one combobox-style multi-select input.

You just need a fuzzy text filter at the top to hide the checkboxes you don't care about.

I think this thread just about proved how insufficient the available controls are.

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

#143

Post by worldsayshi »

egeozcan wrote: post #37
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…

>I can't select multiple non-consecutive items by using just my mouse

Well you can with ctrl-click. A well hidden feature though.

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

#144

Post by egeozcan »

worldsayshi wrote: post #143
egeozcan wrote: post #37

Earlier quoted context omitted.

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…

>I can't select multiple non-consecutive items by using just my mouse Well you can with ctrl-click. A well hidden feature though.

> using just my mouse

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

#145

Post by marcellus23 »

stuartloxton wrote: post #35
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…"

Also, it doesn't let you type-to-select when the box is focused but the dropdown is not expanded.

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

#146

Post by nine_k »

egeozcan wrote: post #141
nine_k wrote: post #137

Earlier quoted context omitted.

200 checkboxes make about as much sense as a 200-item dropdown. Neither is manageable. The multi-select dropdown is additionally hard to check for the selections made. An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative. Another, larger alternative is the typical two-lists control, with selected items moved from the source list to the target list…

> 200 checkboxes make about as much sense as a 200-item dropdown. Neither is manageable. Multi-select is okay there, apart from the problems I mentioned above: https://jsfiddle.net/z0Ltxh47/2/ . I can navigate to i19 with a few key strokes. Only if it were then possible to easily select a1... > An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative…

> And we are back at implementing our custom controls again.

Sadly, yes. Not everything was anticipated at the times of Netscape 2.

HTML5 added a number of native controls, like video players and calendars. I wish a better "native" multi-select alternative surfaced, too. OTOH I suppose that browsers are going to blur the line between "native" controls and web components and such.

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

#147

Post by nedt »

tomger wrote: post #90
egeozcan wrote: post #37

Earlier quoted context omitted.

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…

The js fiddle example works great on iOS. I didn’t realize mobile safari supported a multi-select sheet!

Yes it really is. And now imagine someone would instead use a custom multi-select, because their browser has a bad implementation. Actually the best example why custom form elements shouldn‘t be used.

You can still write one as an add-on for your browser and help others or use it as poc for a ticket to the browser vendor.

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

#148

Post by nedt »

Uehreka wrote: post #68
K0nserv wrote: post #60

Earlier quoted context omitted.

You don’t have to style the select. If you are being forced to, your designers are either incompetent or ignorant. Aesthetics shouldn’t trump usability

By this logic, almost every designer is incompetent or ignorant. Styling form elements is not an extreme position, even if you might want it to be.

Have you ever seen a designer define all the different states with all the different input methods for a select element?

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

#149

Post by MaxBarraclough »

jraph wrote: post #85
ironmagma wrote: post #56

Earlier quoted context omitted.

Say what you will about ActiveX, but it allowed a much more native feel for web pages.

Native feel is not wanted (anymore). Branded appearance is. (and I think this is unfortunate. I wish developers didn't attempt to replace my browser's perfectly fine-looking, accessible checkboxes by their own often ugly custom implementations for instance. And I'm not hating on web devs, I'm one of them) XUL [1] seemed like a good idea as a basis for building native-looking web applications. It's too bad it has been…

> XUL seemed like a good idea as a basis for building native-looking web applications. It's too bad it has been abandoned.

Didn't XUL do roughly what React Native, and other similar frameworks, do today?

edit I see that XUL did its own rendering rather than using native widgets, but the overall goal seems about the same.

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

#150

Post by fuzzy2 »

khepin wrote: post #91

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 coupl…

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