Hacker News Reader

Comment by montroser | Hacker News Reader

Most of this is great, except for the input/datalist bits, which are not sufficiently functional to be used in any real scenario. Users expect these interfaces to be tolerant of misspellings, optional sub text under each option, mobile ux niceties, etc -- and so everyone builds this with js...

View on HN

My main beef with datalist is that there's no easy way to show and allow only text (e.g. Beverly Hills), but have the actual value selected be a number (e.g. 90210). In other words there's no analogy to <option value="90210">Beverly Hills</option>.

That and there's no HTML way to interactively load results. Or are you really going to serialize half a million records to HTML and transfer it all every time the relevant block is added to a page? What if it sits in the header or footer templates?

This would be possible in XSLT, if only browsers would implement the latest spec rather than abandoning it all together.

Right, I sort of expected there to be an attribute for an url.

   <datalist json="search.php?q=toyota+corolla">

But then you would want to send other form values along with it which might make things more complicated than it should be?

Static could be better too. When search engines first started building these auto complete dropdowns the multi word input was really the killer feature. To have something like "green toyota" you would have to generate an element for all color and brand combinations? And the you want it to work for "green toyota corolla" and you get an abc kind of list length.

Perhaps a wildcard would have been fun or regex options.

  <option value="* days"></option>
  <option value="* weeks"></option>
  <option value="* years"></option>

Indeed, and if I have to build a component for it in JS anyway, I'm highly likely to just reuse that component everywhere I need it rather than have to build, style, and test different implementations in the same app.

Half a million might be pushing it, but you'd be surprised how much you can inline without any penalty these days.

> Each <option> element should have a value attribute... It can also have a label attribute, or, missing that, some text content, which may be displayed by the browser instead of value (Firefox), or in addition to value (Chrome and Safari)... The exact content of the drop-down menu depends on the browser, but when clicked, content entered into control field will always come from the value attribute

This seems... underspecified. Not ideal that Chrome/Safari aren't aligned with Firefox here, and that there is no standard way to only display the label

[from]: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

And styling! The default styling of datalists in most browsers is just ugly.

Open an issue with your browser or OS

Default styling being ugly is often for backwards compatibility with older sites so their look stays as consistent as possible. For that reason opening an issue is likely a waste of time for GP and for the devs.

They also are most certainly quite aware of how the default styling looks in their browser. It wasn't an oversight. That's not to say it doesn't pain them, it often does, but it has been intentional

Usually it looks however the native OS toolkit looks, just like everything else in browser. This is pretty new (and not well adopted) tech so it's not about legacy styling considerations (like, say, the default CSS for text being so awful) but rather that the OS no longer looks the way people want it to look by default.

Also datalist is nice but most the time we need a “select” (so users can’t submit anything not in the list), but select doesn’t have search/filtering like datalist has.

Technically native selects do have a very rudimentary form of filtering: start typing text with the select focused and it will auto-select the first matching option.

E.g. if the select is a list of US states, type "N" and it will jump to Nebraska. Continue into "New" and you'll get New Hampshire, etc.

This is better than nothing (and I personally use it all the time) but not a patch on an actual proper select-with-filtering which, yes, you still need JS to implement properly.

On my android phone it just didn't show anything in the drop downs.

Try on a phone, it doesn’t work. Now that’s you create html only and no js you need to test all kind of devices to see quirks and try to fix it. And you’ll end up with more hacks to fix other devices and you end up adding Js. And you’ll have html only and html with js. With is much worse that just properly do it in js.

I can see the op is a js hater even tho he keep saying he’s not. Anyway doesn’t matter. Just a small note.

Reply on news.ycombinator.com