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

151–160 of 227 posts

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

#151

Post by galaxyLogic »

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.

Multi-select is what you have in File Explorer. You can select multiple files and folders for copying or deletion or moving. It is not a disaster

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

#152

Post by nedt »

diegof79 wrote: post #38

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

Oh the combobox element in the WAI ARIA is interesting. On mobile the dropdown can‘t be scrolled without scrolling the page (and the user losing where they were in the form). Also the tap targets are smaller.

And there even is a combobox in HTML5. It‘s an input with a list attribute.

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

#153

Post by mattlondon »

diegof79 wrote: post #38

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

Yep I totally agree with this.

There are however a bunch of ARIA tags & best practices etc (https://w3c.github.io/aria-practices/) that exist to make popups and dialogs (and other things e.g. tree views or "email-inbox-style" "treegrids" etc) accessible (if implemented correctly).

I am conflicted about these - it is nice that there are ARIA tags for this, but it would also be nice if browsers "understood" aria tags and added some default behaviors (e.g. keyboard navigation). As it is, ARIA tags are essentially "pointless" to anyone who doesn't use an assistive technology, and so non-assitive-technology users nor developers benefit from using ARIA tags so they are often forgotten. If the browsers saw that there was an A11y-tree that matched a treeview or a treegrid, it would be really really nice if they applied some default common keyboard navigation implementation, rather than do nothing and leave it up to the developer to decide what keys do what on each and every site. .... Or on the other hand, is that too prescriptive and should we give developers and UX designers more leeway to design something better, rather than rely on browser-enforced defaults? I guess we are happy with browser defaults for basic inputs, but would we be for a treegrid?

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

#154

Post by Shared404 »

com2kid wrote: post #110
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.

Hilariously, lots of good implementations on mobile. Long tap to start, checkbox next to each item that is then selected. Confirm button when done selecting.

I actually really dislike this.

I find that I often have half second hangups due to not remembering if in select mode or not.

Much prefer the "Hold shift/ctrl" model used often in file managers.

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

#155

Post by pc86 »

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.

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 filter changes, allowing you to select anything matching multiple filters.

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

#156

Post by nedt »

lol768 wrote: post #59
msoad wrote: post #45

It's such a blanket statement to say "you can't". Those controls themselves are coded up mostly using JavaScript so it is defiantly possible. It just requires a lot of work. The most accessible component library that I've seen is Adobe Spectrum React[1] which supports all of those nuances mentioned here for all of their controls and allow for styling and customization. [1] https://react-spectrum.adobe.com/react-spect…

> supports all of those nuances mentioned here for all of their controls and allow for styling and customization I don't believe it. Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour. The invisible input field behaviour Drew mentions in the article doesn't work. If I hit backspace, my browser doesn't know I'm i…

Also the picker is broken on iOS. If the bottom navigation bar is hidden the backdrop doesn‘t cover the whole page, which is ugly. More ugly then just a standard select element. Selecting by swiping over the elements doesn‘t work. And sometimes an accidental swipe and tap jumps to the top of the page. If Adobe can‘t support iPhone for everyone with less people power is better off using the existing form elements.

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

#157

Post by easrng »

marcellus23 wrote: post #99
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…

Ugh, Slack too. For ages they didn't have right-click menus anywhere. Then a while ago, they added right-click menus to channels, but of course they couldn't just use the native menus that every OS already has, so it's some HTML abomination that had to rewrite the wheel for handling things like lenient mouse movement (e.g. https://css-tricks.com/dropdown-menus-with-more-forgiving-mo... ). Still doesn't support type-t…

I don't know if Electron has an API for menus, but the HTML elements that let you add items to the native contextmenu were scrapped, and every browser I know of renders their own menus on Windows/Linux anyway. There is not a way to add a native contextmenu unless you do something cursed like positioning an invisible where the mouse is and opening it on right click.

Edit: Never mind, there is no way to open a with JS.

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

#158

Post by easrng »

danielvaughn wrote: post #22
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 I think the web really needs is headless behavior via attributes.

Like onclick, onsubmit, etc? We already have those.

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

#159

Post by marcellus23 »

easrng wrote: post #157
marcellus23 wrote: post #99

Earlier quoted context omitted.

Ugh, Slack too. For ages they didn't have right-click menus anywhere. Then a while ago, they added right-click menus to channels, but of course they couldn't just use the native menus that every OS already has, so it's some HTML abomination that had to rewrite the wheel for handling things like lenient mouse movement (e.g. https://css-tricks.com/dropdown-menus-with-more-forgiving-mo... ). Still doesn't support type-t…

I don't know if Electron has an API for menus, but the HTML elements that let you add items to the native contextmenu were scrapped, and every browser I know of renders their own menus on Windows/Linux anyway. There is not a way to add a native contextmenu unless you do something cursed like positioning an invisible where the mouse is and opening it on right click. Edit: Never mind, there is no way to open a with JS.

I know, but other Electron apps manage to do it (VS Code, Postman), so there must be a way.

edit: some quick googling reveals there is an API for this https://www.electronjs.org/docs/latest/api/menu#class-menu

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

#160

Post by kreetx »

Shared404 wrote: post #154
com2kid wrote: post #110

Earlier quoted context omitted.

Hilariously, lots of good implementations on mobile. Long tap to start, checkbox next to each item that is then selected. Confirm button when done selecting.

I actually really dislike this. I find that I often have half second hangups due to not remembering if in select mode or not. Much prefer the "Hold shift/ctrl" model used often in file managers.

Parent is talking about mobile. And on Android it's working rather well I'd say. The only downside I see is that selecting longer spans (shift click) is not possible.
Post reply on HN