5 ms·

It offers more than a bare input does. Why can’t I add Ajax for fuzzy matches? A custom drop down with keyboard events? Or I could hang all that off of an input

by tdy721 5y ago

It offers more than a bare input does. Why can’t I add Ajax for fuzzy matches? A custom drop down with keyboard events? Or I could hang all that off of an input. Or use a select? You’re saying stuff can’t be done. Out of the box sure? Why hate on it? This looks great to me.

scrollaway 5y ago
The more complex input elements can't always be styled, don't always have events available for things you'd expect etc. A bare input allows you to do those things from scratch, whereas a custom one is useless if you can't build on top of it. It's the curse of complex UI elements on the web. Menu failed for similar reasons.
- beebeepka 5y ago
  Bending other people's higher level solutions to your needs
enlyth 5y ago
I'm not OP but I share his frustration with so many of the built in HTML elements. All of them seem like they're stuck in the 90s and just plain impossible to use for modern UI requirements. As someone who has worked on a lot of UI, one example of a common pattern I've ran into everywhere I've worked at is pic related: https://i.ibb.co/sgyzqYS/picrelated.png https://i.ibb.co/sgyzqYS/picrelated.png It usually has at least the following features: - Mutli-select that displays each item selected in the row - Chevron indicates selection - User can type in to search - Asynchronous loading/search from an API (because too many elements at once) - Custom styling to match whatever your design framework is Yeah no wonder why it's easier to just use React for everything.
- menzoic 5y ago
  I think its a good thing that HTML doesn't bloat itself. It should offer the bare minimum for the ecosystem to build on. There's plenty of free options for extensible advanced UIs built by the open source community. If anything I also think browser vendors should make HTML element styles even more basic and the standard should allow for better custimozation and events instead of locking them down to a style that will get outdated.
- tenaciousDaniel 5y ago
  My issue is that adding any functionality into native UI elements breaks the separation of concerns principle. You're wrapping structure, styling, and behavior all into one package, in a manner that is impossible to disentangle.
- blacktriangle 5y ago
  Stuck in the 90s is generous. Win31 and MacOS both had built-in combo boxes with searching, styling, etc. Meanwhile the browser default multiple select UI is still one of the shittiest UI widgets ever built and its still all we have.
  - colejohnson66 5y ago
    Not only does it suck, it sucks to the point where some developers don’t use it for their forms (they use something better) and cause accessibility issues.
- earthboundkid 5y ago
  I ended up shipping this as a similar autocomplete field: https://github.com/spotlightpa/almanack/blob/master/src/components/BulmaAutocompleteArray.vue https://github.com/spotlightpa/almanack/blob/master/src/comp... It's a little different because I put the chosen selections on a row above the input row, but the principle is the same.

by tdy721 5y ago

scrollaway 5y ago

The more complex input elements can't always be styled, don't always have events available for things you'd expect etc. A bare input allows you to do those things from scratch, whereas a custom one is useless if you can't build on top of it. It's the curse of complex UI elements on the web. Menu failed for similar reasons.

beebeepka 5y ago
Bending other people's higher level solutions to your needs

enlyth 5y ago

I'm not OP but I share his frustration with so many of the built in HTML elements. All of them seem like they're stuck in the 90s and just plain impossible to use for modern UI requirements. As someone who has worked on a lot of UI, one example of a common pattern I've ran into everywhere I've worked at is pic related: https://i.ibb.co/sgyzqYS/picrelated.png https://i.ibb.co/sgyzqYS/picrelated.png It usually has at least the following features: - Mutli-select that displays each item selected in the row - Chevron indicates selection - User can type in to search - Asynchronous loading/search from an API (because too many elements at once) - Custom styling to match whatever your design framework is Yeah no wonder why it's easier to just use React for everything.

menzoic 5y ago
I think its a good thing that HTML doesn't bloat itself. It should offer the bare minimum for the ecosystem to build on. There's plenty of free options for extensible advanced UIs built by the open source community. If anything I also think browser vendors should make HTML element styles even more basic and the standard should allow for better custimozation and events instead of locking them down to a style that will get outdated.
tenaciousDaniel 5y ago
My issue is that adding any functionality into native UI elements breaks the separation of concerns principle. You're wrapping structure, styling, and behavior all into one package, in a manner that is impossible to disentangle.
blacktriangle 5y ago
Stuck in the 90s is generous. Win31 and MacOS both had built-in combo boxes with searching, styling, etc. Meanwhile the browser default multiple select UI is still one of the shittiest UI widgets ever built and its still all we have.
- colejohnson66 5y ago
  Not only does it suck, it sucks to the point where some developers don’t use it for their forms (they use something better) and cause accessibility issues.
earthboundkid 5y ago
I ended up shipping this as a similar autocomplete field: https://github.com/spotlightpa/almanack/blob/master/src/components/BulmaAutocompleteArray.vue https://github.com/spotlightpa/almanack/blob/master/src/comp... It's a little different because I put the chosen selections on a row above the input row, but the principle is the same.