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

https://drewdevault.com/2021/06/27/You-cant-capture-the-nuance.html

by nitsky • 4 years ago

411 223 4 years ago

drewdevault.com

asddubs• 4 years ago

I wish more development went into form widgets. A big thing is also that they're accessible and responsive by default.

One that I would love would be some sort of drag and drop reorderable list, for example.

rjknight• 4 years ago

This is true, but the set of custom controls is quite small. Controls that were built-in to, say, Visual Basic 4.0 in 1995 are not present in today's web browsers.

Re-implementing built-in controls (the example of a <select> box is given in the OP) is obviously a very bad idea in almost all circumstances. Implementing a missing control is a much more difficult decision, and there are times when it can be a defensible choice to do so.

dmitriid3• 4 years ago

Lots of people have been saying this for years, and accessibility voices are now being heard as well. It's extremely difficult to create a proper form control and remember all the usage patterns and all the edge cases.

However, people want more than just the 6 or so controls defined in the 1990s. Even w3c in their design system relies on a third-party autocomplete: https://design-system.w3.org/third-party-plugins/

The reason? Browser implementors rarely solve actual issues that are truly desired by most people. Because browser implementors are low-level C/C++ developers who rarely touch actual web development. So we get 41 distance units, and horrendously bad APIs like Service Workers and Custom Elements, and piles of things like Ambient light sensors [1]. But for all the hype and advertisement around web applications we don't really get things that actually make it easy to, you know, develop these applications. Google Docs is transitioning to canvas and Figma reimplemented half of the browser in WebGL not because web platform is so great.

There's now the https://open-ui.org project that collects common UI patterns that have been endlessly re-implemented across countless frameworks and libs. It will be another 40 years before any of them become a reality.

[1] Yes, it's a thing: https://chromestatus.com/feature/5298357018820608

svkurowski• 4 years ago

I was wondering about this, too.

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.

For my self-hosted minimal CRM (not really ready for anybody except me yet) [Aktenkoffer](https://github.com/svkurowski/aktenkoffer), I created a custom select that allows for filtering/searching of contacts when choosing sender/recipient for a given document. I don't use browser's select because:

1. There's a lot of contacts one has, and the list will become very long, a usecase for which select seems not to be the best fit, i.e. I don't want to load all the options always. 2. I cannot always remember how I formatted a contact name - e.g did I include the "Dr." at the beginning or not. Select quick-selection only works when I know exactly the sequence of characters I'm looking for (like the US state selection the author mentioned).

Obviously it has tons of feature gaps, I.e. pressing Esc does not close it (yet), up-and-down arrows don't work (yet), one cannot just type to go to one option.

Any suggestions, what to do in such a case? And how I can learn more about such approaches?

I love sourcehut, and its design and I would like to follow a closer to the browser, minimal UI but in practice it seems quite hard for me - harder than getting a custom select "half-right".

wffurr• 4 years ago

There's not a great built-in combobox control, which is a shame. An input type=list element with a datalist comes close: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

saint-loup• 4 years ago

Recent discovery: there's a native <datalist> element, well supported except for Firefox@Android. It's a combo of <select> and filtering (a combo box, to use the Windows parlance).

https://developer.mozilla.org/fr/docs/Web/HTML/Element/datal...

theandrewbailey• 4 years ago

The big downside is that datalist will only show exact matches of what you've put in. If you're doing a fuzzy search somewhere (or the user has a typo) and want to offer search suggestions, a native datalist doesn't work. I wish there was an attribute that forced all options to appear when filtering happens elsewhere and options are dynamic.

romaniv• 4 years ago

The best unit of isolation for web functionality is behaviors, not controls. Think of them as traits enabled and configured via attributes. I've used such things on many different projects with very good results. The main advantage is that if you design them properly it is trivial to extend built-in functionality without reinventing the flat tire.

bavell• 4 years ago

Interesting, care to expand on behaviors vs controls?

mihaic2• 4 years ago

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

danielvaughn• 4 years ago

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

easrng2• 4 years ago

Like onclick, onsubmit, etc? We already have those.

egeozcan9• 4 years ago

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 their values, or innerText if no value exist. Horrific.

Accesibility: At least in Firefox, using ctrl+arrows to be able to focus on elements to select them do not render any focus targets. In Chrome, the contrast is not there.

Don't even get me even started with the date/time-picker.

cookiengineer• 4 years ago

How about some checkboxes and labels with the for attribute then?

ironmagma2• 4 years ago

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

marcosdumay• 4 years ago

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.

tomger• 4 years ago

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

cycomanic• 4 years ago

What is the problem exactly seems to work fine on Firefox mobile

worldsayshi• 4 years ago

I can't select multiple non-consecutive items by using just my mouse

Well you can with ctrl-click. A well hidden feature though.

dfabulich• 4 years ago

I have good news for you! https://open-ui.org/

The purpose of Open UI to the web platform is to allow web developers to style and extend built-in web UI controls, such as <select> dropdowns, checkboxes, radio buttons, and date/color pickers.

Their current thinking is to cook a new element, <selectmenu>. Here's a demo of styling it in an experimental version of Chrome. https://www.youtube.com/watch?v=IjHnmaquifM

(They went with a new element <selectmenu> instead of <select styleable=true>, but there's still an ongoing debate about that, and/or how to polyfill it.)

K0nserv3• 4 years ago

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

Uehreka• 4 years ago

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.

closetohome• 4 years ago

Aesthetics shouldn’t trump usability

It's true, and it really shouldn't be as controversial an opinion as it apparently is.

aaronbasssett• 4 years ago

That's an unpleasant thing to say about the people running Hacker News.

Take a look at the search page.

throw_m239339• 4 years ago

I agree 100%. and the fact that there are still only a handful of form controls is just jarring. The people who champion using JS frameworks to make up for the lack of form elements are contributing to the problem, especially on mobile. No library, not even well tested JS ones can make up for the native controls. This is why users do prefer mobile native apps.

mmis10003• 4 years ago

Imagine a custom implemented drop down that just goes out of the screen and make you unselectable. Let alone the item height are just narrow that make you accidentally click something next to it. And yea, that happens all the time.

And as a developer I often need to argue with the designer that please just don't use dropdown on mobile ui when there are many items. That is just a torture for a phone user.

And sometimes I even need to add hidden area to the ui. Because the controls are way too tiny to click.

Usability are not really in their mind., Or probably it is just a bad designer.

cosmotic• 4 years ago

Most websites that use custom components look and feel broken, no matter what the year.

Aeolun• 4 years ago

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.

cabalamat2• 4 years ago

but anyone that has ever needed to style a <select> to make it look in line with any modern design

Then don't make it look "in line with any modern design". Make it look like an HTML select tag, because that's what it is.

Functionality should (nearly always) trump prettification. (Especially when the results are pretty anyway).

ajkjk2• 4 years ago

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 and feel like websites", and people should have the freedom to do whatever they want and not be constrained by arbitrary limitations of bad APIs.

mdoms2• 4 years ago

anyone that has ever needed to style a <select>

No one has ever, in the history of software, NEEDED to style a <select>. You want to style a select. Your users don't give a toss.

yoz-y• 4 years ago

That’s untrue. As long as the UI works, people will prefer a nicely looking one.

SPBS• 4 years ago

What kind of CSS do you need to add to <select>? Do you have an example of this modern design?

rhdunn4• 4 years ago

The dropdown listbox, optgroup labels, and options should all be part of the CSS box model and have all the styling options available. That would allow full styling (including border, margin, padding, text and background colour) and make the listbox match the other element styling.

That would go a long way, but doesn't support more complex UI like checkboxes in the dropdown (for a compact multiselect component), a treeview instead of a listbox (including checkbox support), and highlighting parts of option text for things like autocomplete (with the ability to filter based on what's being typed).

It would also be useful to know if the listbox is being displayed above or below the select, so with a rounded border, you can style both the select input and listbox to have a flat edge on the top or bottom accordingly.

For checkboxes, it should be possible to theme them more easily, including: 1. border width, colour, and radius for the box; 2. a graphic or unicode character for the checked and mixed states; 3. optionally an image for the entire checkbox.

mouzogu• 4 years ago

the web is really a horrible platform to build any kind of high fidelity app. you can say it works despite of itself.

and this is by design, web as a platform is pretty much owned by tech giants like google and apple who have a financial interest in keeping the web from becoming a rich platform which would cut into their app store hegemony.

ironic when you consider iphone and the html 5 back story. in some respects microsoft with IE back in the days was more interested in developing the web as a platform but also saw the web as something they could monopolise whereas now apple takes a more nuanced but just as much devious approach.

hn_throwaway_99• 4 years ago

and this is by design, web as a platform is pretty much owned by tech giants like google and apple who have a financial interest in keeping the web from becoming a rich platform which would cut into their app store hegemony.

Google is guilty of plenty of things, but holding back the web as a first rate development platform is not one of them, and I think the blame falls squarely on Apple's shoulders here.

Just look at what you can do with a PWA on Android. Most importantly, unlike on iOS, you can receive push notifications. But you can also do things like ship a PWA directly to the Play Store, access all sorts of native browser libraries like Bluetooth support and Add to Home Screen.

If you look at non-gaming apps, I'd estimate about 90% of them could be straightforwardly implemented as PWAs. The reason they're not is due to deliberate decisions by Apple not to support the tech that would make that possible, like push notifications.

s17n• 4 years ago

I'd put the blame on designers, since the "modern design" that you are referring to is terrible. We'd all be better off if the web still looked like 2004, and the users would be fine with it too - they only care about "modern design" as a proxy for "this is an actively maintained product".

folkrav• 4 years ago

We'd all be better off if the web still looked like 2004, and the users would be fine with it too - they only care about "modern design" as a proxy for "this is an actively maintained product".

You're declaring this based on what, exactly?

analog31• 4 years ago

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.

scim-knox-twox• 4 years ago

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

shrimpx• 4 years ago

Also how inconsistent the look and behavior is from browser to browser. If you want to achieve uniformity across chrome/safari/ff, you basically have to go custom.

NegativeLatency• 4 years ago

Date inputs are particularly terrible here once you try and do any constraints

LAC-Tech• 4 years ago

I got in trouble for this before. App was using some third party super bloated select-react-component-replacement-made-of-divs, and it wasn't behaving properly. I just replaced it with a select, so then people complained it was ugly.

And I get where they're coming from.

At the same time... native browser controls work, they don't require maintenance, they don't add to the bundle size, or have complex version inter-dependencies.

Maybe it's time to rethink frontend. Maybe what we write should be designed to work with the standard HTML controls.

(Or maybe it's time for me to go back to the backend and play with database, because I feel increasingly out of touch).

martindale• 4 years ago

Agree completely. I'm practically one new-tab-opened-without-me-asking away from forking a browser just to remove this behavior.

montroser• 4 years ago

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 severely UX-challenged such that no professional web site/app would really be able to use them in production. For these, in 2022, we still have no choice but to build custom implementations in order to meet usually expectations.

julianlam• 4 years ago

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.

grenoire• 4 years ago

The browser date pickers will always return YYYY-MM-DD to your server when they send a request. What's exposed to the user is usually localised. This is the behaviour you want.

p49k• 4 years ago

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.

9dev2• 4 years ago

Tangent: I wonder why, after having standards like ISO 8601 for decades, stuff like this is something we even have to think about. On a technical level, there's a need for exactly two date time formats: Monotonically increasing integer timestamps, and ISO 8601 style date time with timezones.

Karellen2• 4 years ago

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.

dmitriid3• 4 years ago

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, you know, if aesthetics or accessibility doesn't work with a native picker I might just use a third-party one instead of requiring my users to switch browsers and OSes.

Native date input have horrendously/hillariously bad implementations in all desktop browsers. I can't even begin to imagine thinking about using them for anything.

9dev2• 4 years ago

This is a strange take: Native date pickers are broken in every mainstream browser, which is what the majority of our users use. People don't consciously "choose" browsers. They use whatever was preinstalled or someone recommended them ten years ago.

Our customers don't care about other browsers, Open Source software, or the nuance of native input fields. "Look, on AirBnb I can enter dates in a humane way, why is it so hard on your website?" - I just don't get away with recommending them to switch browsers.

Having accepted that premise, we can talk about the custom implementations: I would never recommend rolling your own, either. There are several widely used library for date pickers that users are accustomed to, are accessible, and miles ahead of the native controls. There is absolutely nothing wrong with sticking to those libraries until the vendors finally fix their mess.

kmeisthax2• 4 years ago

The funny thing is that, at least on Windows[0], there actually isn't a standard color picker. Or, well, there is, but it's one of those common-controls dialogs that hasn't gotten a UI refresh since Windows 3. People writing native apps that need to pick colors wind up writing their own color pickers[1]. Even Microsoft does this: Paint gives you the same obsolete system color picker I mentioned before, but Paint 3D ships with it's own[2].

If you ask a browser on Windows for a color picker, you get the old-and-busted one. Given the odd bifurcation in Windows UI since 8, I suspect date pickers are the same way, and the one the browser gives you won't actually match what other native apps are doing. So what happens if you decide to do the "right thing", is that you get a demonstrably worse user experience for your forms for the vast majority of people who do not know how to retheme native UI and have zero familiarity with the old Windows controls that browsers continue to throw at people.

[0] macOS has a native color picker that is apparently so good that someone reimplemented it for iPadOS.

[1] Adobe isn't even consistent among their own suite. The Photoshop color picker is entirely different from the Premiere or Animate ones, for example.

[2] I suspect the Paint 3D color picker may be a XAML default, but up until very recently the prospects of actually using XAML in most apps was very dim. More specifically, XAML used to be either exclusive to .NET/C#, or exclusive to Microsoft Store apps, neither of which were conducive to native software that need to live outside of an app container sandbox and be distributed through Steam.

obpe• 4 years ago

I have implemented many custom form controls. The reason is almost always because the design requires it. But other reasons can be to "improve" the control; for the select box to make the invisible edit buffer visible. I appreciate this is not the way but it is also pretty annoying how limited the styling, and customization, of form controls is.

We use Angular so it's pretty easy to hide the custom control and have a plain control for accessibility. At least for checkbox and radio inputs, am I the only one that uses a hidden input to control the style of some div to make it look fancy like the design required?

ryukoposting• 4 years ago

In my (very limited) experience, the "hidden input" approach seems to be a reasonable approach. All the w3schools guides I've followed seem to do it that way.

disclaimer: 95% of my "modern" web frontend experience consists of non-professional goofing off in Svelte.

enlyth• 4 years ago

Sadly this is the "right" way, and as many other commenters in this thread have pointed out, the sad state of default browser components is to blame.

grishka5• 4 years ago

If a designer wants me to do a custom control, I usually explain them why it's a bad idea and instead style the standard one.

Klaster_1• 4 years ago

The UI designers I had worked with do not have much experience working with the web platform as a user or developer, are not aware of capabilities default controls provide and almost never use the products they've designed. Additional exposure of UI compared to under-the-hood stuff begs for additional bikeshedding and micromanagement by people who understand this even less, like management. Maybe I never met good a designer or worked in a company with sane process.

specialist• 4 years ago

Emphatic agreement.

Today, even apparently trivial widgets require ridiculous amounts of effort to attain a "natural" UX. To become so good you don't notice. That holy grail of being "invisible".

Epochs ago, I created custom controls for Win32. The one I was most proud of was a direct manipulation sundial picker for a raytracer. I obsessed over the details. Like being pixel perfect, both mouse and arrow keys (for fine grained increments), live updates between dial widget and text fields. Damn, I was proud of that control. I flushed and preened whenever a user complimented the effort.

Ages ago, I started using bootstrap-select. It's a nifty dropdown w/ type ahead (search). Modest, no big deal, right? Nope! That project received so many PRs, tweaks, fit & finish, finesse, and all around TLC. I was transfixed, fascinated. I haven't done UI for years, but remained subscribed to their project announcements, mostly out of awe and respect.

https://github.com/snapappointments/bootstrap-select

Observing the bootstrap-select project over time humbled me. I used to think I had some UX juice. Now I know that I'm just banging the rocks together.

aarondf2• 4 years ago

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 buffer" thing, look at this control from Headless UI: https://headlessui.dev/react/listbox.

Open it, start typing, and notice the invisible buffer actually does work here.

Cthulhu_2• 4 years ago

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.

aarondf2• 4 years ago

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

mhink• 4 years ago

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.

simion314• 4 years ago

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?

stuartloxton• 4 years ago

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

mrob• 4 years ago

On Firefox on Linux, I get a different incorrect behavior. "To" + backspace + "a" (fast enough that it doesn't trigger the timeout for starting a new search) remains on "Tom...".

hbn• 4 years ago

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

marcellus234• 4 years ago

Also, it doesn't let you type-to-select when the box is focused but the dropdown is not expanded.

nick238• 4 years ago

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.

grishka5• 4 years ago

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

vsareto2• 4 years ago

Numbers vs. names for months is a legit casus belli

Aachen• 4 years ago

Spotify custom implemented this for their desktop client. You could right click on a song, open the submenu "add to playlist", and type a few characters. Idk why they bothered custom implementing that when a select list is a standard element no matter what framework they use, but I was happy. Then cometh the update and the feature be regressed. I now need to use the mouse for literally everything, including looking through this list with no discernable sorting (it's not alphabetical). Only spacebar for play/pause survived, all other keyboard controls seem gone or I can't guess them.

Just use normal components. Save the effort, help the screen reader, please the power user. Please.

marcellus234• 4 years ago

Ugh, Slack too. For ages they didn't have right-click menus anywhere. Then a while ago, they added right-click menus to channels, but of course they couldn't just use the native menus that every OS already has, so it's some HTML abomination that had to rewrite the wheel for handling things like lenient mouse movement (e.g. https://css-tricks.com/dropdown-menus-with-more-forgiving-mo...). Still doesn't support type-to-select, or god knows how many other accessibility and power user niceties.

Phelinofist• 4 years ago

You could organize your playlist in folders. Not a solution but that might make it bearable :P

stereocodes5• 4 years ago

what does this have to do with form fields? edit: I see you think that context menus are form fields. Thats incorrect.

thfuran• 4 years ago

As long as it's not one of the sites that truncates passwords differently at signup and at login, I can probably manage.

mmis10003• 4 years ago

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 in literally any ui framework or a handwritten one if you really don't want to use framework.

bmn__5• 4 years ago

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.

    <input list="administrative_areas" name="PRC_AA" />
    <datalist id="administrative_areas">
        <option value="华北">
        <option value="东北">
        <option value="华东">
        <option value="中南">
        <option value="西北">
        <option value="西南">
    </datalist>

Type `南` to test.

sandruso• 4 years ago

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)

Cthulhu_2• 4 years ago

I prefer to use built-in controls as much as possible, but they have their flaws and missing features. One of my pet peeves / gripes is the half or broken implementation of new HTML5 input fields, like number or calendar inputs. I haven't found working them at all delightful.

peterjmag• 4 years ago

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

reportgunner• 4 years ago

Works on my Win10 machine too.

godot• 4 years ago

This thread just makes me think of the thankless job of native frontend developers working on Linux/macOS/Windows OSes that made these nuances and behaviors work exactly to a specific standard. Ok, maybe not thankless in the case of Mac and Windows since they probably got paid. :) But yeah, I imagine all the edge cases aren't easy to handle.

grishka5• 4 years ago

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 <select> implementation in Chrome/Vivaldi also supports it. None of the custom JS ones support it.

The menu that opens from a <select> 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.

frosted-flakes2• 4 years ago

Your last point is not true. You can set custom dropdowns to close on loss of focus, which will happen when clicking outside of the browser window. It makes debugging with the browaer tools a right pain in the neck, but it's totally possible.

grishka5• 4 years ago

Yes but then that click would still go through to wherever you clicked and activate some other window. System menus consume that click.

tuyiown• 4 years ago

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)

robin_reala3• 4 years ago

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.

lucasmullens• 4 years ago

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.

kmeisthax2• 4 years ago

In some cases the visual requirements are also accessibility-related.

For example, <select> will give you a drop-down that lets you type to pick, but only the first letter, and only letters that directly correspond with a keycode. So you can't type "Uni" to get "United States of America"; you can't type "とうきょう" plus enter to get "東京", and so on. If you need to support IMEs or picking through large option sets, dropdowns are a bad option.

Of course, native UI developers know that you can use a combobox instead of a dropdown picker; but there's no <combobox> tag. You have to implement your own by attaching a bunch of div/event soup to an <input type=text>[0]. In this particular case, doing so will actually make the input more accessible, because keyboard users can just type the answer instead of having to press the first letter and hit down 200 times to get to the thing they want. It's also more internationalized, because you can use your IME to compose the characters you need to search through the list with.

[0] The select2 library will do this for you and it's my go-to if I need a combobox.

bradstewart• 4 years ago

By far the most annoying thing to me (as a user who does not rely on accessibility features) is how few JS-built forms support TABing through the fields, in the correct order. It's infuriating.

diegof79• 4 years ago

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 the best way to have a dropdown list that’s accessible and supports mobile. But, select doesn’t cover most of the cases that you need for a complex app.

Many of the WAI ARIA authoring examples (including the combobox patterns) are not covered by built in components. Interaction patterns like pop ups, dialogs, or lookup lists are quite common for an app… but hard to do in an accessible/cross-platform way.

Web browsers need to do something different to support accessible/usable apps. The idea of leaving all those things to WebComponents makes sense, but the result is reinventing the broken wheel on each app.

nedt4• 4 years ago

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.

extra883• 4 years ago

Do you mean <datalist>? 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

mattlondon• 4 years ago

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 and added some default behaviors (e.g. keyboard navigation). As it is, ARIA tags are essentially "pointless" to anyone who doesn't use an assistive technology, and so non-assitive-technology users nor developers benefit from using ARIA tags so they are often forgotten. If the browsers saw that there was an A11y-tree that matched a treeview or a treegrid, it would be really really nice if they applied some default common keyboard navigation implementation, rather than do nothing and leave it up to the developer to decide what keys do what on each and every site. .... Or on the other hand, is that too prescriptive and should we give developers and UX designers more leeway to design something better, rather than rely on browser-enforced defaults? I guess we are happy with browser defaults for basic inputs, but would we be for a treegrid?

extra883• 4 years ago

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 <header>, <main>, <footer>, 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/

woudsma• 4 years ago

The browser’s built-in controls are quite sufficient.

Until you work on global webshop forms, where business/management wants hundreds of exceptions to the rules. Few examples: form input pre-fills, custom validation, auto-complete fields, fancy dropdowns, email/postcode checks that need to happen while filling in the form. I could go on. And it all should be manageable from some ancient CMS, of course.

eximius• 4 years ago

Can't or don't?

Besides, I usually build controls out of input primitives, not pure JS.

msoad• 4 years ago

It'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-spectrum/index.html

lkxijlewlf• 4 years ago

... defiantly possible

In a lot of cases, yes.

lol768• 4 years ago

supports all of those nuances mentioned here for all of their controls and allow for styling and customization

I don't believe it.

Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour.

The invisible input field behaviour Drew mentions in the article doesn't work. If I hit backspace, my browser doesn't know I'm in an input field and (correctly) navigates me to the previous page.

In Firefox, if I use tab I can select my native <select> and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing.

I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether.

It's such a blanket statement to say "you can't".

It's a blanket statement, sure, but in my experience it's absolutely true and I don't know why it's always frontend JS developers who are arrogant enough to think they can reinvent decades of work on e.g. Gtk in their crappy UI controls library but it's quite tiresome. Spoiler alert: you can't and won't, stop trying.

mattwad• 4 years ago

Nor should we want to! I have spent a week trying just to make my forms screen-reader-friendly and it is very hard, especially if you're using a library already to build the components. But the reason I know it won't work is that all my changes look like weird hacks and are bound to be immediately broken by the next person to work on them that's not using a screenreader.

jakelazaroff• 4 years ago

In Firefox, if I use tab I can select my native <select> and it gets focus styling - not so with Adobe Spectrum React's equivalent control. Once I have focus, I can start typing to select items without opening the dropdown list. Typing whilst I've tabbed on to the React control does nothing. With the native control I can hit space to open up the menu and view the items once I have focus. With the React control, hitting space does nothing.

I just tried the link (in Firefox) and all of these work correctly.

I also looked at elements like the switch and checkboxes. With native components I can click in the empty space before a form control and be confident that the next <Tab> press I perform will focus the control for me. This behaviour doesn't work with Adobe Spectrum React's equivalent control's - I end up tabbing straight over the components altogether.

What do you mean, "click in the empty space before a form control"?

stereocodes5• 4 years ago

in both examples where you claim this doesn't work it worked for me. clicking on an empty space next to the form element and hitting tab focused correctly for me. Also tabbing then starting to type worked as well. I tested in FF and Chrome. Are you sure the options exist in the select box when you type? That would make it seem like type completion doesn't work. I Tried the checkbox and radio buttons example in FF and Chrome both auto select the field and using arrow keys to make options selected worked just like native. I think the error is somewhere between keyboard and chair.

phh• 4 years ago

Just tried the picker https://react-spectrum.adobe.com/react-spectrum/Picker.html and within 30 seconds you can find divergences from the browser's behaviour.

Took me exactly three key presses. I navigate using vimium. I just don't know how to pick anything on vimium without my mouse on this, while standard select work just fine.

nedt4• 4 years ago

Also the picker is broken on iOS. If the bottom navigation bar is hidden the backdrop doesn‘t cover the whole page, which is ugly. More ugly then just a standard select element. Selecting by swiping over the elements doesn‘t work. And sometimes an accidental swipe and tap jumps to the top of the page. If Adobe can‘t support iPhone for everyone with less people power is better off using the existing form elements.

wellthisishn• 4 years ago

Try Tom Select: https://tom-select.js.org/examples/

Any initial impressions on that one?

badsectoracula• 4 years ago

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.

Vinnl• 4 years ago

This is such a fantastic library. Gave me a far better shot at making my work accessible than I'd otherwise have.

padseeker• 4 years ago

This is an interesting comment but also an edge case. I build custom components all the time, such as a combo box that allows a user to select a list of options but also allows the user to type in a fragment and the options will be displayed filtered based on the text fragment typed. I would imagine your use case is a nightmare, but the average dev team and product manager is probably myopic and anglo-centric so they are more worried about the average latin language based user as opposed to your use case.

I'm glad you are sharing this, its good to be aware of and I might share this with my own product team in the future.

codeptualize2• 4 years ago

This is not helpful imo. Although it correctly identifies a problem of badly implemented controls. The explanation and solution show a lack of knowledge and understanding about the topic and current situation.

It's easy to say "use just the browser provided controls" until you actually have to build something that people need to use. What is expected today from even a simple form involves a lot of custom behavior that browsers do not provide, at what point is it "custom"? Advising against that will not help things become more usable nor accessible.

Instead of "just don't do it", I suggest to promote caring about usability and accessibility, and make people realize it should be evaluated for each individual situation and give practical information on how to do that.

Very basic practical advice; Use native elements where possible, if you run into their limitations preferably use an existing well build and maintained alternative that does implement all of the intricate details. Building something completely custom should be a last resort, if you do end up in that situation it's often beneficial to build it on top of something else.

shadowgovt• 4 years ago

Agreed. I think about custom controls like I think about cryptography libraries: most hackers aren't specialized enough to have thought through all the corner cases and unless you want that to be your specialty, you're taking on a lot of risk of blowing your own leg off (metaphorically speaking) trying to hack out a solution instead of using something (ideally) well-maintained and with some history behind it.

(Having had some experience working on custom controls in a browser: it's the kind of project that will occupy a three-person team at a Fortune-500 full-time over multiple quarters to get right. Set your expectations accordingly.)

withinboredom2• 4 years ago

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.

codeptualize2• 4 years ago

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 as described in the article.

I also don't think it's correct to say accessibility and usability come for free as long as you use plain html elements. You can build really horrible unusable forms with plain html elements, I've seen plenty (and I've probably build a few myself in the past haha).

My point is; "don't use X" and "don't do Y" posts are not helpful as they do not convey the point that both usability and accessibility require effort and consideration, and give a false sense of "if you don't do this all will be great" which is not the case.

karaterobot• 4 years ago

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+ items. We used this control in 10-15 different places, usually inside a spreadsheet cell. Which built-in controls should I use for this? I agree with the author that it is difficult to implement.

jaywalk• 4 years ago

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.

vsareto2• 4 years ago

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.

LinAGKar2• 4 years ago

Same with links, for example when someone makes a JavaScript link and breaks the middle click to open in new tab

bandie91• 4 years ago

many +1 and add target=_blank to the list.

LinAGKar2• 4 years ago

Yes, definitely

kevincox4• 4 years ago

In Firefox there is an option to override this in about:config so that all links open in the same tab.

However the downsides including breaking some OAuth authentication flows and sometimes you can't open fake links in new tabs when you want to.

However for me the consistency is still worth the minor breakagaes.

khepin• 4 years ago

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 couple numbers in a form field because someone thought they'd be smart...

fuzzy2• 4 years ago

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

account42• 4 years ago

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.

scelerat2• 4 years ago

"no, but we want our customers to have an immersive brand experience"

- egos

stereocodes5• 4 years ago

As I type into a regular textarea on this site I'm wondering where these textarea replacements on websites are? I'd love for a few examples of this happening. "Many" JS programmers recreate the textarea? Show me.

strager• 4 years ago

Facebook, Twitter, Gmail, Discord

kevincox4• 4 years ago

It depends exactly what you mean by textarea. If you need rich text you need something custom. (Although you can use contenteditable as a base)

There are sites like GitHub that slightly enhance a regular textarea (IIRC it is a textarea, haven't thought about it too much)

gjvc• 4 years ago

The sooner we stop attempting to fool each other that DOM + CSS is a suitable model for composing user interfaces which were previously implemented as native apps, the sooner we will get past the web era and on to something better.

(25 years later... still trying.)

stereocodes5• 4 years ago

LOL

rhdunn4• 4 years ago

The main issue here is that the listbox on a select control is not part of the DOM+CSS model. If it was then there wouldn't be as big a problem, as they could be styled and customized while still taking advantage of native functionality.

timwis• 4 years ago

The browser’s built-in controls are quite sufficient.

What do you recommend for a typeahead/autocomplete? In my case I’m using a third party API for results (geocoding), but even with a static list, the closest option is datalist, which is very limited

danschumann• 4 years ago

"The most efficient system is no system" -Elon Musk

blacklion3• 4 years ago

It is why I hate Electron apps which disguise themselves as native ones.

olliej• 4 years ago

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”

awinter-py• 4 years ago

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.

kevincox4• 4 years ago

To be fair Google Docs is a bit different here. To a large extent their goal is to display what is going to be printed (this is changing a bit with the new pageless mode and things like checkboxes but still is the core). So doing all of the rendering themselves actually makes sense.

That being said I would love to see a rich-text input with some default controls available.

bob10292• 4 years ago

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.

bmn__5• 4 years ago

Theoretically, you could replicate nearly the entire experience if you were patient and determined enough.

Practically, impossible, because browsers do not expose information about keyboard shortcuts respectively the associated semantic actions to the JS runtime environment, so a programmer looking to replicate has to make assumptions and hardcode keys.

Waterluvian• 4 years ago

Number inputs have given me the most pain. The trick is that you need to manage two states: the current string state of the input and the most recent valid number state or null or NaN or whatever you want.

The issue being that there’s many valid numbers that aren’t always parsable numbers as a human types them in (because of decimal or negative, etc.)

astrea• 4 years ago

Calendar date selectors and phone number fields that try to automagically format my phone number into some predefined format (usually (xxx)-xxx-xxxx) and insert characters are the bane of my existence.

ycui1986• 4 years ago

Digikey changed their website last year and the specific nuance the article mentioned is not being implemented. Made my life a bit more miserable when purchasing electronics components.

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

Related Stories