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

21–30 of 227 posts

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

#21

Post by aarondf »

Cthulhu_ wrote: post #18
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…

But... why not style the built-in controls? I mean in addition to this keyboard UX, there's accessibility to consider; screen/braille readers, alternative input methods, etc.

I mean... you have to know that styling the default controls usually falls vastly short of what you're trying to do.

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

#22

Post by danielvaughn »

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.

What I think the web really needs is headless behavior via attributes.

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

#23

Post by p49k »

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.

> 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 complaining about how ridiculously broken and unusable it is.

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

#24

Post by peterjmag »

Double clicking selects a word, and triple-clicking selects the whole line. If I double- or triple-click-and-hold, I can drag the mouse to expand the selection word-wise or line-wise, not just character-wise. This works with the paragraphs of text in the body of this blog post, too.

I had no idea that you could end with a drag to expand your selection by word or by line like that. That's really cool. (The author's using Linux, but it works on macOS too.)

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

#25

Post by grishka »

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, including a dropdown, can only close it when you click within the browser viewport, for obvious reasons. System popup menus (NSMenu I think?) are kinda system-modal in that you can close them by clicking anywhere on screen, which is more convenient.

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

#26

Post by tuyiown »

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

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

#27

Post by mhink »

Cthulhu_ wrote: post #18
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…

But... why not style the built-in controls? I mean in addition to this keyboard UX, there's accessibility to consider; screen/braille readers, alternative input methods, etc.

Because in a lot of cases, browsers don't expose the necessary APIs to do so. That being said, most component libraries I've seen that implement custom controls (which do expose APIs to allow styling) will make a point of adding all the necessary ARIA attributes to make controls properly accessible.

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

#28

Post by simion314 »

Cthulhu_ wrote: post #18
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…

But... why not style the built-in controls? I mean in addition to this keyboard UX, there's accessibility to consider; screen/braille readers, alternative input methods, etc.

>But... why not style the built-in controls?

As devs we don't decide, we get soem designs, like make a numeric input that looks like in this picture, make a select that can show a different icon for each option()like a language select with flag icons)), or make a font select that each item has it;s own font family.

Then you have stuff that are clasic things in normal GUI toolkits like accordions, tree views, very efficient grid/list views(I mean a widget where you can load 10K items and not have to implement your own smart loading or the lazy pagination way).

I did not done too much mobile but I remember there are some "tabbed/stacked views" , you can put your components in this views and would be efficiently loaded and unloaded when you moved from one view to other making things start faster and use less memory.

Not sure why the browser makers ignore this stuff, did they give up and we just have to use third party libraries for simple things like a good select and a working GridView?

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

#29

Post by Karellen »

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…

A native date input might be inconsistent between different browsers, or different OSs, but it will be consistent with the native date input on every single other website the user goes to. If they're lucky, it will be consistent with the date input field on every other application on their OS.

The only intuitive interface is the nipple. Everything else is learned. If the user has leaned how to use the native date picker on their browser, they know how to use the date picker on your website.

If you make them learn how to use a new date picker for your website, it's very unlikely they'll thank you for being able to transfer this unique knowledge to that one website of yours on the very unlikely chance they choose to switch browsers. I mean, who does that regularly?

And if the native date picker in their browser doesn't work for them - maybe because aesthetics, maybe because accessibility - they can either pick a different theme for their browser, or pick a different browser. (Or a different OS!) That has the advantage of fixing the native date picker on every single website they go to. Except for the annoying websites which implement their own, where if the custom date picker doesn't work for them, they're fucked.

If someone's using a browser with an date picker you happen to dislike, that's their choice. Let them have it.

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

#30

Post by reportgunner »

peterjmag wrote: post #24

Double clicking selects a word, and triple-clicking selects the whole line. If I double- or triple-click-and-hold, I can drag the mouse to expand the selection word-wise or line-wise, not just character-wise. This works with the paragraphs of text in the body of this blog post, too. I had no idea that you could end with a drag to expand your selection by word or by line like that. That's really cool. (The author's us…

Works on my Win10 machine too.
Post reply on HN