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

181–190 of 227 posts

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

#181

Post by analog31 »

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.

I'd be perfectly happy if your website looks like the OS platform it's running on. That way, I already know how to recognize and use the controls before I arrive. Granted, I'd blame the browsers if those controls weren't accessed by default.

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

#182

Post by shrimpx »

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.

Also how inconsistent the look and behavior is from browser to browser. If you want to achieve uniformity across chrome/safari/ff, you basically have to go custom.

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

#183

Post by NegativeLatency »

shrimpx wrote: post #182
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.

Also how inconsistent the look and behavior is from browser to browser. If you want to achieve uniformity across chrome/safari/ff, you basically have to go custom.

Date inputs are particularly terrible here once you try and do any constraints

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

#184

Post by ehnto »

marcosdumay wrote: post #76
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…

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.

The most robust solution is to individually toggle selected state on each item, and don't unselect all on a new click. Like a checkbox. Click once for selected, once to unselect, don't unselect all on any click.

A multi-select drop down is just solving the problem of a checkbox list being too long, or not what the designer wants it to look like. The most clear UI for this input type is a set of checkboxes in my opinion. Same for a single item select and radio buttons.

Drop downs have a lot of caveats, and unique compositions in the wild, so many of them are inaccesible and it's essentially just because someone wanted it to look pretty. I think that is bad software.

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

#185

Post by ehnto »

nkrisc wrote: post #173
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.

If your UI has 200 checkboxes displayed at once, in an ideal world you’re rethinking your requirements and redesigning the UI. The only way to make a 200 item select box usable is to make it not a 200 item select box somehow.

By filtering to search, which is also a UI fraught with inaccesiblity if not very carefully designed. I think custom elements aren't the issue here really, it's the lazy implementations.

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

#186

Post by derefr »

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.

Are we? Why wouldn't we just push OS vendors to add "input box with pill-style auto-completion" as a native toolkit widget, and then have browsers expose it? The OS vendors have proven willing to add stuff like native OS date/time/number-picker widgets, so why not this one?

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

#187

Post by nkrisc »

ehnto wrote: post #185
nkrisc wrote: post #173

Earlier quoted context omitted.

If your UI has 200 checkboxes displayed at once, in an ideal world you’re rethinking your requirements and redesigning the UI. The only way to make a 200 item select box usable is to make it not a 200 item select box somehow.

By filtering to search, which is also a UI fraught with inaccesiblity if not very carefully designed. I think custom elements aren't the issue here really, it's the lazy implementations.

Think bigger even. In an ideal world, if you have that many options you might want to rethink the entire workflow. I understand in the real world that may not be an option, but it’s still probably the ideal state.

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

#188

Post by sleightofmind »

blacklion wrote: post #164
pc86 wrote: post #155

Earlier quoted context omitted.

Multiselect over a range of 200 arbitrary values isn't something that will ever be solved by a single control, so that's a complete straw man. If you actually need to multi-select over 200 arbitrary values (you almost certainly don't), the best way to do it I've seen is a way to filter the displayed items, a "Select All" button for what's visible based on that filter, and maintaining the "checked" state through filte…

this problem was solved around 1986 by Norton Commander and one of the main reasons why two-panel file managers (FAR, mc, TotalCommander) are still in use. When you decouple selection with cursor and make selection "permanent", so you can move around this list without fear to lose accumulated selection, you could pick needed elements one-by-one, sort list by any attributes to simplify selection, apply filters, etc.

Yep. When marking many files for selection the twin-pane file managers let your mind (and your stomach) rest easy. I sometimes use ranger with two or more tabs to similar effect.

There was/is a Tcl/TK twin-pane file manager I liked called FileRunner. It's showing it's age now and needs a rewrite -- not for beauty, which I'm not too concerned about, but for some glitches that have crept in with time and lack of maintenance. It seemed more mouse friendly than some other twin-pane FMs (or maybe it's just rose-tinted memory).

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

#189

Post by saagarjha »

hn_throwaway_99 wrote: post #176
5350-uiop-1130 wrote: post #122

Earlier quoted context omitted.

the web is really a horrible platform to build any kind of high fidelity app. you can say it works despite of itself. and this is by design, web as a platform is pretty much owned by tech giants like google and apple who have a financial interest in keeping the web from becoming a rich platform which would cut into their app store hegemony. ironic when you consider iphone and the html 5 back story. in some respects m…

> and this is by design, web as a platform is pretty much owned by tech giants like google and apple who have a financial interest in keeping the web from becoming a rich platform which would cut into their app store hegemony. Google is guilty of plenty of things, but holding back the web as a first rate development platform is not one of them, and I think the blame falls squarely on Apple's shoulders here. Just look…

iOS is adding the ability for web apps to send push notifications.

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

#190

Post by folkrav »

s17n wrote: post #178
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.

I'd put the blame on designers, since the "modern design" that you are referring to is terrible. We'd all be better off if the web still looked like 2004, and the users would be fine with it too - they only care about "modern design" as a proxy for "this is an actively maintained product".

> We'd all be better off if the web still looked like 2004, and the users would be fine with it too - they only care about "modern design" as a proxy for "this is an actively maintained product".

You're declaring this based on what, exactly?

Post reply on HN