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

131–140 of 227 posts

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

#131

Post by rhdunn »

SPBS wrote: post #108
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.

What kind of CSS do you need to add to ? Do you have an example of this modern design?

The dropdown listbox, optgroup labels, and options should all be part of the CSS box model and have all the styling options available. That would allow full styling (including border, margin, padding, text and background colour) and make the listbox match the other element styling.

That would go a long way, but doesn't support more complex UI like checkboxes in the dropdown (for a compact multiselect component), a treeview instead of a listbox (including checkbox support), and highlighting parts of option text for things like autocomplete (with the ability to filter based on what's being typed).

It would also be useful to know if the listbox is being displayed above or below the select, so with a rounded border, you can style both the select input and listbox to have a flat edge on the top or bottom accordingly.

For checkboxes, it should be possible to theme them more easily, including: 1. border width, colour, and radius for the box; 2. a graphic or unicode character for the checked and mixed states; 3. optionally an image for the entire checkbox.

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

#132

Post by crooked-v »

nine_k wrote: post #129
marcosdumay wrote: post #76

Earlier quoted context omitted.

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.

A separate multi-select control is just a bad idea from 1990s; it should be disused and forgotten. The proper way is a list of checkboxes. Checkboxes are easy to recognize, easy to style, and easy to navigate and operate.

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

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

#133

Post by mdoms »

yoz-y wrote: post #106
mdoms wrote: post #104

Earlier quoted context omitted.

> anyone that has ever needed to style a No one has ever, in the history of software, NEEDED to style a . You want to style a select. Your users don't give a toss.

That’s untrue. As long as the UI works, people will prefer a nicely looking one.

> As long as the UI works,

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

#134

Post by timwis »

> 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

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

#135

Post by rhdunn »

gjvc wrote: post #124

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

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.

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

#136

Post by K0nserv »

aaronbasssett wrote: post #128
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

That's an unpleasant thing to say about the people running Hacker News. Take a look at the search page.

I think my statement is truthful, albeit harsh.

I don't believe there are many designers who are interested in creating experiences with poor usability, thus my point about ignorance and not understanding the tradeoff they are making. On "incompetence", if a designer understands fully that they are creating something that will be less useable and accessible for the sake of aesthetics they have earned the label. To take the HN search page as an example, the filters can't be interacted with via keybord or screen reader. When it's your job to help users solve problems and you have made it knowingly harder to do that, I don't see how that's competent.

Luckily, it has been my experience that in most cases(including my own) the former, rather than the latter, is at play.

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

#137

Post by nine_k »

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

Earlier quoted context omitted.

A separate multi-select control is just a bad idea from 1990s; it should be disused and forgotten. The proper way is a list of checkboxes. Checkboxes are easy to recognize, easy to style, and easy to navigate and operate.

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; this idiom was widely used in Windows since 1990s. It's not mobile-friendly though.

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

#138

Post by earthboundkid »

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

Earlier quoted context omitted.

A separate multi-select control is just a bad idea from 1990s; it should be disused and forgotten. The proper way is a list of checkboxes. Checkboxes are easy to recognize, easy to style, and easy to navigate and operate.

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.

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

#140

Post by marcellus23 »

stereocodes wrote: post #117
Aachen wrote: post #36

Earlier quoted context omitted.

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

what does this have to do with form fields? edit: I see you think that context menus are form fields. Thats incorrect.

It's not about form fields, it's about type-to-select. No one said anything about context menus being the same as form fields.
Post reply on HN