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

201–210 of 227 posts

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

#201

Post by NoSorryCannot »

bmn__ wrote: post #193
ajkjk wrote: post #100

Earlier quoted context omitted.

I feel like it's important to establish that "controls should look like the browser intended and not be customizable" is an ideological stance, not an obvious and self-evident truth. And it's one that I strongly disagree with, because it's needlessly controlling: why shouldn't developers me able to make something look however they want? The web is a platform for _all kinds of creations_, not just "website that look a…

I feel like it's important to establish that "controls should look like the Web designer intended and be customizable" is an ideological stance, not an obvious and self-evident truth. And it's one that I strongly disagree with, because it's needlessly controlling: why should Web designers be able to make something look however they want? The web is a platform for _all kinds of users_, not just "websites that look and…

Gross.

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

#202

Post by 8n4vidtmkvmk »

nine_k wrote: post #146
egeozcan wrote: post #141

Earlier quoted context omitted.

> 200 checkboxes make about as much sense as a 200-item dropdown. Neither is manageable. Multi-select is okay there, apart from the problems I mentioned above: https://jsfiddle.net/z0Ltxh47/2/ . I can navigate to i19 with a few key strokes. Only if it were then possible to easily select a1... > An input box with pill-style auto-completion (see e.g. the tags control on Stackoverflow) would be a reasonable alternative…

> And we are back at implementing our custom controls again. Sadly, yes. Not everything was anticipated at the times of Netscape 2. HTML5 added a number of native controls, like video players and calendars. I wish a better "native" multi-select alternative surfaced, too. OTOH I suppose that browsers are going to blur the line between "native" controls and web components and such.

I think there's an initiative to improve these... but I can't find it at the moment. Googling anything with "native" just turns up react-native crap.

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

#203

Post by 8n4vidtmkvmk »

bmn__ wrote: post #196
mmis1000 wrote: post #103

Earlier quoted context omitted.

As a chinese user, I don't know this function until now. Character in chinese requires multi keystroke. And the IME won't be even triggered when you are not focusing a text field, render the whole function useless. So, a common pattern here is "use combobox instead". Because combobox has a working input field build-in, make it usable with chinese. But.... the HTML don't have combobox build-in, so you end up get one i…

> HTML don't have combobox build-in Yes, it does. Supported in browsers since 2010, specified earlier. You have not taken the time to research this topic. Type `南` to test.

It's not very good tho. It offers some autocomplete suggestions once you type the first character, but there's no indicator that there's a hidden list there. It seems if you double click on the input you can pull up the full list, but no one would know that.

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

#204

Post by rhdunn »

extra88 wrote: post #161
mattlondon wrote: post #153

Earlier quoted context omitted.

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…

The WAI-ARIA Authoring Practices are not best practices, they are not carefully researched to ensure they can be successfully used in a variety of browsers or with a variety of assistive technologies. They include examples that don't work properly with common browser/screen reader combinations (like Safari + VoiceOver). They'll use ARIA approaches even when they're not the only or best way to achieve a goal. They're…

The open-ui is only potentially good when you need something that resembles the standard controls and interactions. At the moment it only has a few controls specified and if you need anything not covered by those you are going to end up creating your own UI -- e.g. using a treeview dropdown instead of a listbox, or if you have a form with multiple checkboxes and need that group of checkboxes to be a role=select from an ARIA perspective in order to place form error messages on that group so that screen readers read the error set on the ARIA description, but still display as a list of checkboxes to the user.

When you have custom UI, then you need to mark that up in a way that is accessible and implement things like keyboard navigation properly. No matter how many standardized UI elements you create there will always be cases where you need to use ARIA markup and not just for styling/theming, but for accessibility as well like in my form error example above.

The ARIA authoring practices is the best thing I know of that does that, along with other resources like www.a11ymatters.com for patterns like pagination.

If you are saying that the authoring practices isn't good enough, then what we need is a battle tested guide on how to implement all of the UI patterns (disclosure, dialog, select, etc.) that works on all screen reader/browser combinations and documents all current features (ARIA, keyboard, dark mode, reduced motion, styling/theming, etc.). It should also include notes on what issues and resolutions to look out for, and details on what users of assistive technologies are looking for (e.g. when and what content should be read out).

You can (and should) have a set of common components that implement these patterns in a way that can easily be styled to handle 80% of the use cases. But there should also be a way to support the other 20% of use cases -- which is what ARIA was designed for.

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

#205

Post by jcelerier »

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

Earlier quoted context omitted.

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…

An input box like SO's isn't discoverable though, it's not good for things that you "want but don't know exist yet"

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

#206

Post by account42 »

fuzzy2 wrote: post #150
khepin wrote: post #91

Worst of those I encounter regularly is US sites trying to constrain your input to numbers only on certain fields. Not "letting you input anything and marking it invalid if you put something other than a number", but listening to which key is pressed to allow the typing or not. On French keyboards, typing a number requires the use of the SHIFT key. So I regularly need to change my keyboard layout just to type a coupl…

Oh yeah I had that recently in a project (IE support required, so no type=number). When you try this, you will eventually find that you use so many keys during normal operation that a whitelist just isn't feasible. Left, right, tab, Home, End, Ctrl+C/V, Shift+Ins, …

Throwing away keys is never the right thing to do anyway. If the user typed 5y8 you don't know if they meant 58 or if the y was meant to be a 6 or 7 so the best thing to do is to have the field contain the full user input and higlight the input as invalid rather than silently guessing what the user meant.

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

#207

Post by scim-knox-twox »

analog31 wrote: post #181
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'd be perfectly happy if your website looks like the OS platform it's running on. That way, I already know how to recognize and use the controls before I arrive. Granted, I'd blame the browsers if those controls weren't accessed by default.

What you want is mostly already here - just use native HTML elements.

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

#208

Post by tentacleuno »

p49k wrote: post #23
julianlam wrote: post #15

Earlier quoted context omitted.

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.

> I don't understand this sentiment. Why would it matter whether the UX is different between browsers for a date or colour input? It’s not just a question of consistency: some of HTML UI elements are still in pre-alpha stage in modern browsers, almost completely broken, despite being part of the standard for many years. It’s a joke. For an example, check out the RANGE element; you will find no shortage of articles co…

> For an example, check out the RANGE element; you will find no shortage of articles complaining about how ridiculously broken and unusable it is.

Could you shed some more light on this? I couldn't find anything from a cursory search. Looking at the W3Schools demo[0], it doesn't look too bad (other inputs set the bar really low). Is it not very friendly with styling? I hear that a lot when people talk about native browser controls.

[0]: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_i...

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

#209

Post by withinboredom »

codeptualize wrote: post #98
withinboredom wrote: post #66

Earlier quoted context omitted.

I’ve used browser controls for the last 20 years on any form I’ve ever implemented. These days you get validation errors, accessibility, and so much more for free — even if JavaScript is turned off. I can’t think of a reason you’d ever want to use a custom control on a form.

How about a date range, search fields with dynamic autocomplete, rich content dropdown selects, combined multi selects, etc etc? As I said in my original comment; I agree that where possible normal input elements are preferred, but they do not cover all cases. I guess it depends on what you consider custom, most of those use html form elements underneath, but they definitely require implementing the intricate details…

> How about a date range

Two separate date fields?

> search fields with dynamic autocomplete

a select control with some js to inject the option tags?

> rich content dropdown selects

I don't even know what this means. Are you just writing code for visual users?

> combined multi selects

I've never run into an average user who knows how to use multi-selects or how to use the shift/ctrl key to do it. I think checkboxes/radio buttons is probably a better and more useable control.

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

#210

Post by mmis1000 »

bmn__ wrote: post #196
mmis1000 wrote: post #103

Earlier quoted context omitted.

As a chinese user, I don't know this function until now. Character in chinese requires multi keystroke. And the IME won't be even triggered when you are not focusing a text field, render the whole function useless. So, a common pattern here is "use combobox instead". Because combobox has a working input field build-in, make it usable with chinese. But.... the HTML don't have combobox build-in, so you end up get one i…

> HTML don't have combobox build-in Yes, it does. Supported in browsers since 2010, specified earlier. You have not taken the time to research this topic. Type `南` to test.

I think this don't really work as a combo box on firefox, more like auto complete.

It is some what a replacement on chrome, because chrome decide to show it with arrow point to bottom.

And in both firefox and chrome. It don't even have a indicator display by default to tell you "you are supposed to select it, not type it" or "Type yourself is invalid, you need to use predefined options".

Post reply on HN