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

51–60 of 227 posts

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

#51

Post by frosted-flakes »

grishka wrote: post #25

Yes. Very much this. Another example: default macOS dropdowns allow you to click and drag while holding the button to select something in one single gesture. Default implementation in Chrome/Vivaldi also supports it. None of the custom JS ones support it. The menu that opens from a extends outside of the browser viewport which makes it easier to choose from long lists. Anything that opens a custom popup menu, includi…

Your last point is not true. You can set custom dropdowns to close on loss of focus, which will happen when clicking outside of the browser window. It makes debugging with the browaer tools a right pain in the neck, but it's totally possible.

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

#52

Post by mrob »

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

On Firefox on Linux, I get a different incorrect behavior. "To" + backspace + "a" (fast enough that it doesn't trigger the timeout for starting a new search) remains on "Tom...".

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

#53

Post by grishka »

frosted-flakes wrote: post #51
grishka wrote: post #25

Yes. Very much this. Another example: default macOS dropdowns allow you to click and drag while holding the button to select something in one single gesture. Default implementation in Chrome/Vivaldi also supports it. None of the custom JS ones support it. The menu that opens from a extends outside of the browser viewport which makes it easier to choose from long lists. Anything that opens a custom popup menu, includi…

Your last point is not true. You can set custom dropdowns to close on loss of focus, which will happen when clicking outside of the browser window. It makes debugging with the browaer tools a right pain in the neck, but it's totally possible.

Yes but then that click would still go through to wherever you clicked and activate some other window. System menus consume that click.

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

#54

Post by 9dev »

julianlam wrote: post #15
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…

I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input? In the end, if it inserts a date, or a hex colour representation, then I am happy. Although now that I think about it, there's a chance a date input would return `mm-dd-yyyy` or `dd-mm-yyyy` depending on locale. To have it return a unix datetime would probably be easier for everybody.

Tangent: I wonder why, after having standards like ISO 8601 for decades, stuff like this is something we even have to think about. On a technical level, there's a need for exactly two date time formats: Monotonically increasing integer timestamps, and ISO 8601 style date time with timezones.

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

#55

Post by frosted-flakes »

grishka wrote: post #53
frosted-flakes wrote: post #51

Earlier quoted context omitted.

Your last point is not true. You can set custom dropdowns to close on loss of focus, which will happen when clicking outside of the browser window. It makes debugging with the browaer tools a right pain in the neck, but it's totally possible.

Yes but then that click would still go through to wherever you clicked and activate some other window. System menus consume that click.

Not on Windows, with the exception of the Ribbon control in the File Explorer and Microsoft Office.

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

#56

Post by ironmagma »

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…

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

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

#57

Post by padseeker »

This is an interesting comment but also an edge case. I build custom components all the time, such as a combo box that allows a user to select a list of options but also allows the user to type in a fragment and the options will be displayed filtered based on the text fragment typed. I would imagine your use case is a nightmare, but the average dev team and product manager is probably myopic and anglo-centric so they are more worried about the average latin language based user as opposed to your use case.

I'm glad you are sharing this, its good to be aware of and I might share this with my own product team in the future.

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

#58

Post by dfabulich »

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 have good news for you! https://open-ui.org/

> The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as dropdowns, checkboxes, radio buttons, and date/color pickers.

Their current thinking is to cook a new element, . Here's a demo of styling it in an experimental version of Chrome. https://www.youtube.com/watch?v=IjHnmaquifM

(They went with a new element instead of , but there's still an ongoing debate about that, and/or how to polyfill it.)

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

#59

Post by lol768 »

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 in an input field and (correctly) navigates me to the previous page.

In Firefox, if I use tab I can select my native and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing.

I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether.

> It's such a blanket statement to say "you can't".

It's a blanket statement, sure, but in my experience it's absolutely true and I don't know why it's always frontend JS developers who are arrogant enough to think they can reinvent decades of work on e.g. Gtk in their crappy UI controls library but it's quite tiresome. Spoiler alert: you can't and won't, stop trying.

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

#60

Post by K0nserv »

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.

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