Hacker News Reader

Comment by tdy721 | Hacker News Reader

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.

View on HN

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

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.

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.

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.

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.

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.

I ended up shipping this as a similar autocomplete field: 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.

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.

Bending other people's higher level solutions to your needs

Reply on news.ycombinator.com