Nice article! I have a question... why do you do this invasive customisation?
Why recreating a custom element that behaves like the native one, inteoducing a lot of code, possible bugs, accessibility issues (keyboard navigation and type filter) that is not integrated with the os (like on mobile)? Does this element deserve all of this time just to have a "custom style"? Is this really an accessibility issue?
With a custom select you will completely lose the native datalist element (which is being imemented by all browsers) and you also have to recreate the optgroup element.
I personally prefer my os integrated dropdown let the platform doing the rest.
Maybe this would work well as Web-Component, also.
Yes this is a classic use case for web components, and if you can't make a web component you should just use both native and custom elements. BTW You can already make a native select with search using the <datalist> element that is being implemented.
Hi, so normally we would use the native HTML elements and style them appropriately. And if this were a side project, I'd use the browser styling. But often when building a design system, you use custom elements to convey your design language and branding. Thus, custom-styled elements are necessary. That's why I made this!
But often when building a design system, you use custom elements to convey your design language and branding. Thus, custom-styled elements are necessary. That's why I made this!
I think this is true when you add functionalities to the custom component, but it's not true if you are replicating the exact behaviour by just adding a custom dropdown. This is a sort of "personal taste" that cause a lot of issues to developers and designers. In my opinion such element is a critical one and it should deserve the right considerations. Also i don't think a custom drop down will invalidate a design system effectiveness, this means that you should have and use the native select, and then make a new custom component to that add more funcionalities other than datalist, multiple select and optgroup (that coming with the native select).
If you add the proper accessibility considerations, screen reader capability with ARIA and keyboard navigation with tabindex, it's just as accessible as the native element. So there's no accessibility benefit over the native element if they're equal in terms of interaction. If I can make a more visually appealing element that adds value and personality to my app, while ensuring compliance with the W3C standards, I'm going to do it.
There are just a lot of things to consider/recreate:
Keyboard navigation (arrows and tabs) and activation (enter)
Select status (disabled)
Options status (disabled, selected, hidden)
User accessibility preferences (high contrast, reduced-transparency and reduced-motion)(Check this demo)
Options group element (<optgroup>)
Dropdown reposition based on the distance from window edges.
Dropdown vertical overflow with a long list
Mobile usability (custom select are almost always unusable on smarphones)
Fieldset element integration...
Multiple selection
All of these thing must be recreated. A lot of effort and possible breaking bugs just to add a custom experience (not better for all) and a custom style. In design systems these things are considere UX breaking.
BTW, i agree with you that this operation must be done if it provide a real value, but at this point, it's not a custom dropdown, it's just a new component. 👍🏻 Cheers.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nice article! I have a question... why do you do this invasive customisation?
Why recreating a custom element that behaves like the native one, inteoducing a lot of code, possible bugs, accessibility issues (keyboard navigation and type filter) that is not integrated with the os (like on mobile)? Does this element deserve all of this time just to have a "custom style"? Is this really an accessibility issue?
With a custom select you will completely lose the native datalist element (which is being imemented by all browsers) and you also have to recreate the optgroup element.
I personally prefer my os integrated dropdown let the platform doing the rest.
Regards.
As soon as you need integrated search, or icons on the options, the native select won't do. And sometimes you can't talk the client out of it.
Maybe this would work well as Web-Component, also.
Yes this is a classic use case for web components, and if you can't make a web component you should just use both native and custom elements. BTW You can already make a native select with search using the <datalist> element that is being implemented.
jsfiddle.net/equinusocio/yj9fb7Lx/4/
Hi, so normally we would use the native HTML elements and style them appropriately. And if this were a side project, I'd use the browser styling. But often when building a design system, you use custom elements to convey your design language and branding. Thus, custom-styled elements are necessary. That's why I made this!
I think this is true when you add functionalities to the custom component, but it's not true if you are replicating the exact behaviour by just adding a custom dropdown. This is a sort of "personal taste" that cause a lot of issues to developers and designers. In my opinion such element is a critical one and it should deserve the right considerations. Also i don't think a custom drop down will invalidate a design system effectiveness, this means that you should have and use the native select, and then make a new custom component to that add more funcionalities other than datalist, multiple select and optgroup (that coming with the native select).
BTW that's just my opinion. :)
If you add the proper accessibility considerations, screen reader capability with ARIA and keyboard navigation with tabindex, it's just as accessible as the native element. So there's no accessibility benefit over the native element if they're equal in terms of interaction. If I can make a more visually appealing element that adds value and personality to my app, while ensuring compliance with the W3C standards, I'm going to do it.
There are just a lot of things to consider/recreate:
<optgroup>)All of these thing must be recreated. A lot of effort and possible breaking bugs just to add a custom experience (not better for all) and a custom style. In design systems these things are considere UX breaking.
BTW, i agree with you that this operation must be done if it provide a real value, but at this point, it's not a custom dropdown, it's just a new component. 👍🏻 Cheers.