41–50 of 227 posts
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, includi…
Besides, I usually build controls out of input primitives, not pure JS.
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.
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…
Earlier 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…
How about some checkboxes and labels with the for attribute then?
...And then to make that drop down pretty, and the checkboxes look neat, we'll set their opacity to 0 and remove pointer events, use CSS to style the label and set a nice looking tick using the 'before' content, which changes when the checkbox is selected... And oh, there again!
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
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.
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-spect…
In a lot of cases, yes.
Earlier 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…
How about some checkboxes and labels with the for attribute then?
and then it gets complicated very quickly: https://jsfiddle.net/wdqjyvsu/1/
You also have still undiscovered problems: How to let people filter the options if you have lots of them (and don't say ctrl+f because it doesn't restrict the search within the element)? What about lazy-loading if you have lots and lots and lots of them?
Usability is not improved, it takes too much space now. API is even worse. Accessibility is improved contrast-wise but all the tabbing is not very friendly, and try using that with a screen-reader. It takes ages to make a selection.
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…
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.
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 pic…
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.