Selects are the absolute worst when it comes to customization. I totally understand it from a design perspective, but I will always push back on it aside from customizing the box itself. The actual dropdown options? Sorry, they're going to look how they look.
Custom JavaScript controls can't capture the nuance of form fields (2021)
71–80 of 227 posts
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#72The nuances should be exposed in a stylable, implementable and a documented API, with examples and guidelines. I don't understand why accessibility promoters endlessly bash developers, while the problem is that the edge between visual requirements and proper accessibility is extremely hard to dance, whereas it's mostly a non issue on proper platforms (eg. Cocoa/SwiftUI)
But… that’s when as a developer you push back. Visual requirements don’t take the place of accessible components in countries where there’s a legal requirement for accessibility, which includes most of north america.
> there’s a legal requirement for accessibility
In the US I'm fairly sure there's only a requirement for accessibility if you're building something for the government. I'm certainly allowed to build a website that isn't accessible and not have it taken down.
Edit: Guess there's precedent to require some businesses to do it as well. Looks like I'm mostly wrong here.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#73Earlier 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.
It's not that it isn't an extreme position, but I think you are right that many(most?) designers don't appreciate the usability tradeoffs they are requesting in doing so. Most designer I've had this discussion with have come around to not doing styling like this after having the tradeoffs explained to them.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#74Selects are the absolute worst when it comes to customization. I totally understand it from a design perspective, but I will always push back on it aside from customizing the box itself. The actual dropdown options? Sorry, they're going to look how they look.
Me wishing every UI/UX person understood this.
In fact, the more bells and whistles I find on the requirements for individual form inputs, the more annoying it is the work on.
Simplicity is god for most of front-end.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#75> Making a custom form control with JavaScript is going to make life worse for a lot of people. Just don’t do it. The browser’s built-in controls are quite sufficient. An extremely common use case at the last two companies I've worked at is a multi-select dropdown with autosuggest. Optionally, new items can be added to the list. Sometimes we needed to use ajax to populate the list, because you were searching 25,000+…
[deleted]
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#76I'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…
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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#77Earlier quoted context omitted.
No offense, but this feels like trying too hard to make the argument that a perfectly normal pattern is somehow too obtuse to be considered. I'm guessing you're trying to argue that something like a pill autocompleter is more appropriate for specific use cases (e.g. the `to:` field in email clients). And sure, sometimes some controls are better suited than others depending on the use case, but that doesn't necessaril…
Your implementation has a lot of accessibility problems AND requires javascript AND doesn't work on firefox mobile. Also: Congratulations, we collectively proved the article wrong. It says, "The browser’s built-in controls are quite sufficient". Here we see that you usually can't "just use standard controls", and even when you do, you need a lot of JS on top to make them accessible, usable, nice to look at with an ac…
> has a lot of accessibility problems AND requires javascript
I'm not sure what you're arguing for then, it feels like you're just hating for its own sake. Because obviously not using standard controls and auto-including aria attributes will require JS too. Turn off javascript and CSS as you're arguing for, and then come back with a proper working implementation and then let's talk :)
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#78Earlier quoted context omitted.
But… that’s when as a developer you push back. Visual requirements don’t take the place of accessible components in countries where there’s a legal requirement for accessibility, which includes most of north america.
> there’s a legal requirement for accessibility In the US I'm fairly sure there's only a requirement for accessibility if you're building something for the government. I'm certainly allowed to build a website that isn't accessible and not have it taken down. Edit: Guess there's precedent to require some businesses to do it as well. Looks like I'm mostly wrong here.
You’re required under the ADA to make “reasonable accommodations” for people with disabilities. This has been tested numerous times in court, most recently against Dominos: https://blog.ericgoldman.org/archives/2021/06/domino-pizzas-...
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#79I'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.
Most websites that use custom components look and feel broken, no matter what the year.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#80It'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…
I think the real issue here isn't if JS control can or cannot (they certainly can) but that even if they can, they still wont behave like the native controls because the native controls depend on the native platform.
E.g. imagine if someone is using a modified Gtk library that uses vi-like shortcuts/modes for multiline text areas. This wont work on custom JS controls. Or something more likely, someone using macOS which, AFAIK, has text edit controls that understand some Emacs-like shortcuts. Even if you sniff their OS from the user-agent or whatever and use macOS-like keys, the user still wont get the text functionality exposes via, e.g. the Services menu.
Of course at the end of the day you may not care about such details - or care but you consider other things more important or have other concerns/limitations for the entire underlying system.