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)
191–200 of 227 posts
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#192Earlier quoted context omitted.
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…
The js fiddle example works great on iOS. I didn’t realize mobile safari supported a multi-select sheet!
Even in desktop Firefox (on linux) I immediately tried to:
- Multi-select by Ctrl+clicking on other items I want selected. (works)
- Shift-click to expands the selection linearly from the focus (works)
- Select one item, then Shift+Up/Down arrows to expand the selection. (Works)
I bet a custom control would be missing most of that behaviour as well.
Mind you, those affordances are completely unknown to most users. I bet if you asked most users (even developers) how to select multiple items in that control, 9/10 would struggle. The input control doesn't make its affordances obvious at all.
So in all, I'm confused what the browser vendors expect people to do here. I'd love to use the built in controls. But as others have said, they're often ugly, they confuse people, their APIs are a mess and they're difficult to style.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#193Earlier quoted context omitted.
> but anyone that has ever needed to style a 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).
I feel like it's important to establish that "controls should look like the browser intended and not be customizable" is an ideological stance, not an obvious and self-evident truth. And it's one that I strongly disagree with, because it's needlessly controlling: why shouldn't developers me able to make something look however they want? The web is a platform for _all kinds of creations_, not just "website that look a…
I feel like it's important to establish that "controls should look like the Web designer intended and be customizable" is an ideological stance, not an obvious and self-evident truth. And it's one that I strongly disagree with, because it's needlessly controlling: why should Web designers be able to make something look however they want? The web is a platform for _all kinds of users_, not just "websites that look and feel like a Web designer wants to", and people should have the freedom to use a site in whatever way they want and not be constrained by arbitrary limitations of bad custom form controls.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#194Earlier quoted context omitted.
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…
> macOS has a native color picker that is apparently so good that someone reimplemented it for iPadOS.
I recall the colour picker being one of the first features that blew my mind upon getting my first Mac running 10.3. I could save swatches OS-wide, I could switch between different selection modes (and install custom modes of my own), and I could even use an eyedropper-like tool to sample any pixel on the screen.
There's probably some LinkedIn allegory about attention to detail in there.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#195Earlier quoted context omitted.
Yep I totally agree with this. There are however a bunch of ARIA tags & best practices etc ( https://w3c.github.io/aria-practices/ ) that exist to make popups and dialogs (and other things e.g. tree views or "email-inbox-style" "treegrids" etc) accessible (if implemented correctly). I am conflicted about these - it is nice that there are ARIA tags for this, but it would also be nice if browsers "understood" aria tags…
The WAI-ARIA Authoring Practices are not best practices, they are not carefully researched to ensure they can be successfully used in a variety of browsers or with a variety of assistive technologies. They include examples that don't work properly with common browser/screen reader combinations (like Safari + VoiceOver). They'll use ARIA approaches even when they're not the only or best way to achieve a goal. They're…
> 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).
Opera 12 does that. It predates ARIA, so it navigates based on the elements available at that time. Default keys (Tools → Preferences → Advanced → Shortcuts → Keyboard setup → Edit… → Input context and shortcuts → Document Window):
• a : Highlight next URL
• q : Highlight previous URL
• s : Highlight next heading
• w : Highlight previous heading
• d : Highlight next element
• e : Highlight previous element
I can mash the keys like crazy to get where I want. The browser is super responsive, keyboard navigation is a joy to use.
The browser also offers spatial navigation (Shift + arrow keys), this navigates interactables not by their functionality, but by their apparent position to each other.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#196It'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.
As a chinese user, I don't know this function until now. Character in chinese requires multi keystroke. And the IME won't be even triggered when you are not focusing a text field, render the whole function useless. So, a common pattern here is "use combobox instead". Because combobox has a working input field build-in, make it usable with chinese. But.... the HTML don't have combobox build-in, so you end up get one i…
> HTML don't have combobox build-in
Yes, it does. Supported in browsers since 2010, specified earlier. You have not taken the time to research this topic.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#197> 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 acc…
> 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.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#198Earlier quoted context omitted.
Bonus points for when the month is the name of the month.
Numbers vs. names for months is a legit casus belli
For credit cards though it's not — your card has the expiration month as a number on it. The form should take a number so you don't have to pause for several seconds to convert one to the other.
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#199I'd actually put the blame here on browsers, and how limited the default inputs are. There are too many needlessly reimplemented components, but anyone that has ever needed to style a to make it look in line with any modern design quickly reached desperation. I'd love to be able to use standard components everywhere, but most of my users care if my website looks like it's from 2004.
I 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).
Re: Custom JavaScript controls can't capture the nuance of form fields (2021)
#200Number 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.)
[deleted]