Hacker News Reader

Comment by joshstrange | Hacker News Reader

> datalist

I agree with most of these (I haven't played with dialog enough to have an opinion) but datalist is not a valid choice IMHO unless it's an internal tool. It's ugly, limited in what you can do, and not style-able. This is the problem with a lot of the "just use the built-ins" (looking at you date picker), not only are the defaults not great but you can't change them even if you want to. As soon as you hit one of the many brick walls when it comes to styling or changing behavior (Oh you want the week to start on Monday? Too bad) then your only choice often is to reach for a full replacement library that, yes, uses JS.

I'm all for using the lighter-weight options and agree with HTML > CSS > JS hierarchy but sometimes JS is the only answer if you want to make your UI look nice and have the features you want.

View on HN

I was implementing a search suggestion box, and thought that datalist could help. It works fine until you want to display options that don't strictly start with what's been typed in, e.g. if the input is misspelled, no options will show. There's no way to force it to display everything, so I opted for an ordered list instead.

Always worth noting that using JS to extend the built-in semantic markup is a future-forward approach. When I started working in web development, changes took up to a decade (IE6 held us all back, but the w3c was also fairly toothless back then). Now they happen quickly. Next year, datalists may be stylable in the big three without prefixing but you'll be beholden to your custom JS solution because business won't pay to rebuild. If you use JS to extend the native functionality you can always remove the JS at lower cost when the support is acceptable. Also with this approach, where the native controls are acceptable you can use it now and just apply the JS as a polyfil

Are you aware of any frameworks that take this approach? For example, if I could import their Datalist and use it, but at build or maybe runtime it decides what to use based on the target environment? We of course have this for tons of things like language features.

I don’t mean to be snarky but: have you ever worked at a company where that would be acceptable?

“Hey Boss, I know this looks like shit today and is missing a ton of features but maybe one day we can enhance it”

That wouldn’t fly and since I make components to wrap just about anything we use (third party or custom implementations) so I’m not beholden to it, I can always rewrite that component to use data list (or whatever built-in) if and when it grows up. Also some code gets written once and practically never touched again so my chances to go back and enhance data list as browsers progress is kind of a fairy tale, at least at all the companies I’ve worked at,

The parent advocates extending functionality of native until no longer required, rather than coding your own and having to maintain it indefinitely.

Not using native as-is.

The issue is that you literally cannot extend the native functionality in many cases.

> (looking at you date picker), not only are the defaults not great but you can't change them even if you want to. As soon as you hit one of the many brick walls when it comes to styling or changing behavior (Oh you want the week to start on Monday? Too bad)

For the start day of the week (and most suggested customizations of input[type=date]), it's a good thing that this is outside of your control. The appropriate calendar to display should be locale-dependent. The user's platform already has capabilities to configure and display this is a way most likely for the user to be able to effectively use.

The platform's date picker is better than whatever weird thing you custom built.

No it's not

Reply on news.ycombinator.com