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

81–90 of 227 posts

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

#81

Post by Aeolun »

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 mean, we don’t need custom browser components. We need certain functionalities that just cannot be given by default components without a ton of ugly hacks.

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

#82

Post by egeozcan »

lhorie wrote: post #77
egeozcan wrote: post #69

Earlier quoted context omitted.

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

I'm arguing that you DO need custom controls. Did you read the thread?

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

#83

Post by vsareto »

grishka wrote: post #34
nick238 wrote: post #16

It's suuuper annoying when the type-to-pick-dropdown doesn't work. Mildly annoying for US states, I live in Illinois, so when it flashes "Idaho", "Louisiana", oh boy. These are usually the forms that then have a 'fake' dropdown for credit card expiration dates, so I can't type-to-pick the month/year either.

Bonus points for when the month is the name of the month.

Numbers vs. names for months is a legit casus belli

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

#84

Post by gbear605 »

lucasmullens wrote: post #72
robin_reala wrote: post #31

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

Judges have found that retail websites are subject to the ADA[1], and sites for things like utilities definitely are. Your personal website does not need to comply though, since it’s not considered a public space.

[1]: https://myblindspot.org/2017/09/retail-websites-are-public-a...

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

#85

Post by jraph »

ironmagma wrote: post #56
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…

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

Native feel is not wanted (anymore). Branded appearance is.

(and I think this is unfortunate. I wish developers didn't attempt to replace my browser's perfectly fine-looking, accessible checkboxes by their own often ugly custom implementations for instance. And I'm not hating on web devs, I'm one of them)

XUL [1] seemed like a good idea as a basis for building native-looking web applications. It's too bad it has been abandoned.

[1] https://en.wikipedia.org/wiki/XUL

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

#87

Post by egeozcan »

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.

There are problems even with the single selection (searching for an option in mobile, consistent contrast, copying selected value etc.).

Depending on the application, sometimes to fix such problems, you need to reimplement the component in js or you start won't fix'ing tickets.

So articles like this really underestimate the problems with the existing controls and the lack of some.

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

#88

Post by brimble »

K0nserv wrote: post #73
Uehreka wrote: post #68

Earlier quoted context omitted.

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.

Speaking of design trade-offs, I've found it's really hard to get stakeholders to appreciate the cost of implementing designs. Design cost should be part of the trade-off give-and-take of figuring out what can fit in a release or sprint or whatever, but often all those decisions happen too early in the process to do that. It's easy for one design decision to affect several "stories" and add tens of "points" (in typical agile terminology) to a project, and entirely possible that the stakeholders would rather have five more features than have that widget look and behave just so. Most designers don't seem to consider this much.

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

#89

Post by hbn »

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

I just tried this with a native in Safari, Chrome, and Firefox and they all worked like the Headless UI version, where a single backspace clears your entire buffer.

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

#90

Post by tomger »

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…

The js fiddle example works great on iOS. I didn’t realize mobile safari supported a multi-select sheet!
Post reply on HN