"no, but we want our customers to have an immersive brand experience"
- egos
Custom JavaScript controls can't capture the nuance of form fields (2021)
111–120 of 227 posts
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#112I 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 choo…
Recent discovery: there's a native element, well supported except for Firefox@Android. It's a combo of and filtering (a combo box, to use the Windows parlance). https://developer.mozilla.org/fr/docs/Web/HTML/Element/datal...
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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#113Earlier quoted context omitted.
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
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.
Many designers I have worked with got into UI design from a graphic design/art/print background[1]. Many I have worked with had never read so much as a word from any OS platform's human interface guidelines and were, indeed, ignorant of HCI fundamentals.
[1] graphic design is a completely legitimate field and a good way to get into UI design, but if that's all you've got, you still have quite a way to go
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#114As 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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#115For 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 pic…
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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#116Double 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.
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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#117It'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.
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 t…
what does this have to do with form fields? edit: I see you think that context menus are form fields. Thats incorrect.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#118The 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)
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.
In some cases the visual requirements are also accessibility-related.
For example, 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 tag. You have to implement your own by attaching a bunch of div/event soup to an [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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#119I'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.
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
> Aesthetics shouldn’t trump usability
It's true, and it really shouldn't be as controversial an opinion as it apparently is.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#120Earlier quoted context omitted.
> 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 horrendo…
Someone with particular accessibility needs might not be using a popular desktop browser - they'll already be using a user-agent which is adapted to their own needs. If you use native input elements, then whatever accessibility needs a user might have can be accommodated by a user-agent which caters to those needs. And you get that to take advantage of that for free. If you roll your own, you can't cater to people wi…
> Someone with particular accessibility needs
Accessibility is not black and white. I have good vision, and native date pickers as implemented in all desktop browsers, are so tiny, I have to zoom the page every time I encounetr them.
> If you roll your own, you can't cater to people with disabilities that you haven't considered.
True, but you out of hand dismissed huge swaths of people who are not using "adapted user-aganets" but still suffer because browsers have a shitty native implementation.