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

161–170 of 227 posts

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

#161

Post by extra88 »

mattlondon wrote: post #153
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…

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 best thought of as patterns designed to "exercise" a browser's support for ARIA attributes, browser developers can use them to test whether their implementation of ARIA support matches expectations.

Nevertheless, some of them are perfectly good solutions as-is and can serve as a good starting point.

I would also like browsers to have more capabilities "baked in;" browsers should offer keyboard navigation of ARIA landmarks (both implicit ones created by , , , etc. and explicit `role` attributes). I don't like the idea of browsers automatically creating interactive controls based on the presence of ARIA attributes, I'd rather there be new HTML elements, ones that document stylability much better than old ones did.

I'm interested in Open UI's [0] work, attempting to develop common web components, ones that can be useful in the short term and may serve as the basis for new HTML elements in the future. They're sort of documenting cow paths that HTML in the future can pave, similar to HTML5 elements being named based on common class names or useful additions to JavaScript having been based on features in libraries like jQuery (obviously without adopting jQuery's syntax).

[0] https://open-ui.org/

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

#162

Post by extra88 »

nedt wrote: post #152
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.

Do you mean ? It doesn't meet all use cases (especially if what needs to be listed requires dynamic updating) but browser support slowly has gotten better.

Unfortunately, I recently heard that all the major browsers fail to resize the datalist text on zoom (my guess is it's rendered outside the DOM, like the browser's UI).

Bug report for Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1756203

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

#163

Post by sandruso »

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.

I just figured out one thing: when delay between keystrokes is < 100ms or less the search through options works and it will highlight Illinois. (Chrome)

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

#164

Post by blacklion »

pc86 wrote: post #155
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.

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

this problem was solved around 1986 by Norton Commander and one of the main reasons why two-panel file managers (FAR, mc, TotalCommander) are still in use.

When you decouple selection with cursor and make selection "permanent", so you can move around this list without fear to lose accumulated selection, you could pick needed elements one-by-one, sort list by any attributes to simplify selection, apply filters, etc.

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

#166

Post by olliej »

I think a real problem here is that people (especially English only) do not understand the actual complexity of most standard input controls. They really think it’s just “type letters”. The number of times I’ve seen people showing their “fully functional” editors that flat out do not work with IM[E]s, do not handle basic keyboard controls, do not handle pasting or search propErly never ceases to amaze me.

That’s before consider breaking all the password or address auto fills, screen readers, non-keyboard text entry.

Even if all you’re doing is “restyling” controls, how do you interact with people who have vision difficulties like colour blindness? You’re restyling overrides accessibility features that make controls visible.

Seriously, you don’t get to say “web apps should be just as capable as normal apps”, and also say “I should break basic app functionality”

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

#167

Post by awinter-py »

google docs reimplemented their whole UX in canvas, and this is a giant company that controls browser standards as much as anyone does. can't think of a louder way to admit defeat re advanced text entry on the web

I wonder about unbundling the different pieces of the browser. Sandboxing + safe-ish remotely-managed code is really cool. Zero-install apps is cool-ish, but comes with slow loading (try opening a new tab in gmail on my poor linux firefox).

But for UX things are tricky. The DOM is somehow simultaneously the best widgets library and a horrible widgets library. CSS isn't quite powerful enough, hence all the scroll jank tricks many sites are still doing, hence the difficulty of mixing classes and getting sane results.

I'd want a browser-like execution context, but with something more like JSX than the DOM, pluggable layout engines with the default one more like modern constraints languages than CSS, SPA-aware RPC primitives, and more attention paid to the customizability of text entry and scroll.

Electron IDEs are simultaneously great (so powerful and customizable) and really bad (built on the worst text entry tech you could pick).

the author is 99% right about the difficult of interacting with custom controls, possible exception of companies like shopify and stripe that have put massive investment into getting this stuff to work cross-platform.

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

#168

Post by mihaic »

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.

That was my initial point actually: a lot of these tradeoffs happen accidentally since for instance you have to write a custom component to do something basic as changing the background color of a select options.

If more powerful browser components would be available then designers would be happy to just style those, and functionality and accessibility would still be fine.

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

#169

Post by bob1029 »

> You cannot capture all of this nuance in a home-grown form control, or even anything close to it, but many JavaScript programmers do it anyway.

In practical terms for most developers, this holds true. Theoretically, you could replicate nearly the entire experience if you were patient and determined enough. Depending on the kind of product you are going for, it could make sense to invest in this capability.

Even accessibility can be addressed by doing things like dynamically inserting DOM nodes that screen readers can see. This is something I have played around with in my canvas/mjpeg/x264 rendering systems.

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

#170

Post by munk-a »

pc86 wrote: post #155
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.

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

Usually with 200 or so values there is some categorization of values that exists - maybe it's counties in a state that can be divided into regions or songs by an artist that can be divided into album or period. Large multi-selects seem to necessitate a multi-step selection process where the user can drill down (All of this category, none of this one and some of this other one - specifically this, this, not this and that). I think it's feasible for such a tag proposal to make its way through various working groups but it'd be pretty opinionated and we'd likely end up dividing multi-select inputs into several different classes (which would probably be a good thing).
Post reply on HN