Hacker News Reader

Comment by appplication | Hacker News Reader

This was a fun little read. Just through testing the examples, I also learned datalist does not seem to work well on mobile safari (which is a large enough market I might even say there’s essentially no scenario in which it’s worth using if there’s a compatibility issue).

View on HN

The datalist examples definitely work on my iPhone. They integrate into the autocomplete suggestions above the native iOS keyboard. There’s no way to browse all the suggestions, but I suppose that’s not an intended use case for datalist.

However, the disabled attr on group definitely does not work!

That’s funny, in my case it tries to autofill my contact information

It seems the autofill bar only populates with the first three items in the datalist and also does not clear when navigating to a regular text field like this one. Kind of an interesting way to have screwed it up.

It initially populates with the first 3 options, but it also updates as you type, with what appears to be a case-insensitive prefix filter.

Way back when I was working my first job, datalist didn’t work on Firefox. That’s what got Firefox removed from the list of supported browsers.

It has been a problem for a long time if you want to support anything other than Chrome.

> It has been a problem for a long time if you want to support anything other than Chrome.

That's partially because Chrome keeps adopting standards nobody else wants to support.

Both things can be true. Chrome supports a bunch of non standard APIs but it also has some of the best coverage of standard APIs.

With Google coming up with most of the new stuff and having chairs in the committees, that's hardly surprising.

Ugh this is the dose of cold water from reality that I didn't want but definitely needed.

More than a decade ago I had a project that used a pretty aggressive input-suggestion widget on the UI. We used a jQuery plugin for it and it was by far the most complicated part of the frontend. In fact, it was the main use-case for jQuery in that project.

Reading the article, I thought it would be pretty much a breeze re-implementing that frontend in a lightweight JS-minimalist version. But of course, unless I ship my machine to the users, not really. Sad state of affairs.

Nonetheless, I'm really impressed with what's included in the HTML spec nowadays! I haven't kept-up with developments in the spec since I read all about XHTML in high school. I ought to take some time every now and then to see what's changed though, again, browser compatibility is a PITA today as it was back in high school.

Doesn't work with Firefox on Android either.

They work well but not with GBoard on iOS.

Mind that input + datalist is the HTML equivalent of the Windows combobox, once generally regarded as the worst UI element ever. (This was enjoying meme status in usability related articles and write-ups. So probably not a recommendation.)

What’s the better alternative for letting the user input arbitrary text with an easier way to input known options?

The general consensus used to be that questions should be either closed (i.e., all the knowledge is disclosed in the interface) or open (any in-between doesn't help to organinze and conceptionalize thought) and that UI elements should signal this appropriately. Now, with autocomplete, there's a use case for this. But there seem to be two types of users, those who make ready use of this and those who ignore it completely, maybe hinting at the question being still open.

(We may observe how the implementation of datalist reflects this: it's still a simple textbox, i.e. input element, and the list is attached as an add-on, rather than being a list type of its own. It's not a list standing on its own, but an enhancement to the input field. So, rather don't use it as a control element for lists?)

PS: The point was really that, if you were to google "worst interface element", you got loads of articles about the combobox.

Reply on news.ycombinator.com