Hacker News Reader

Comment by perlgeek | Hacker News Reader

So, here is the thing. Modern browsers (at least Firefox and Chromium, haven't tried the others in a while) have AWESOME autocomplete widgets for their URL bars.

They incorporate multiple data sources (URLs and page titles from history, bookmarks, the search engine's keyword autocompletion, probably more), build statistical models (when I start typing "y" I want to go to Youtube 95% of the time, so suggest that first), don't clobber my paste buffer even though they pre-select some text, and so on. Awesome all around.

Could we PLEASE get this exact same widget with pluggable data sources available as a HTML <input> element or similar?

Every time I build a web app, I feel that the user experience could be so much better if I had such an awesome autocomplete widget available. None of the javascript implementations come even close.

View on HN

I agree, Firefox's Awesome Bar is the single best implementation of combining local and web results I have ever used. You can even set local results to appear at the top so the order of items doesn't jump around once the Google results are loaded and populated in the dropdown.

Yup. 10 years later, Chrome doesn't even come close to Firefox's implementation.

Don't worry, Firefox is sure to fix that in an update any time now.

The closest we have now is datalist[1], which acts as a data source that you can attach to a text input to give it autocomplete. Unfortunately, it isn't nearly as fully-featured as it could be, possibly because no one uses it so there's no incentive to make it better (although Chrome's implementation has gotten markedly better over the past two years or so, mostly by fixing blatant bugs).

[1] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/da...

I've only used it with a static set of options, not pulling data from ajax and it's been awesome for that.

There are two problems with adding widgets to browsers:

1: Once they are in, you have to support them forever. Or you will break the few websites that use them.

2: Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown. You might not even see something as simple as a native radio button.

I think it's better to get the basics right instead of building more and more 'userland' type of functionality into the browser itself.

> 2) Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown.

I'd argue that's because the native widgets haven't changed much since I've started using computers around 1994 (probably longer), and simply aren't up to the modern standards anymore.

If there was a native widget that worked better than any of the current javascript-enhanced widget and could be styled to fit the website around it, lots of people would use it. Maybe not the top 50 web pages in world, but lots of developers with lower budgets would.

    that's because the native widgets haven't changed much

So why aren't they updated?

If browser makers can't maintain something as simple as a radio button, they will probably not be able to maintain more complex widgets.

Browser engines are already so complex that even a giant like Microsoft gave up on maintining one. And Firefox is spending over $200m in software development per year to keep up.

>If browser makers can't maintain something as simple as a radio button, they will probably not be able to maintain more complex widgets.

Who said they "can't maintain it"? They just wont, which is different. Besides, it is up to HTMLWG/W3C to expand on those widgets, and they have done nothing...

>Browser engines are already so complex that even a giant like Microsoft gave up on maintining one.

Not because of them having radio buttons and form controls. Those we had since Mosaic... Even Lynx supports those.

It's all the other craziness (from 3D, to MIDI, to sound APIs, to 2-3 layout engines, to crazy CSS features).

It’s not even that they won’t, it’s that the radio button doesn’t do the thing you want it to. The radio button works, perfectly, as much as it ever did. There are no issues, regressions, or any such thing.

It is perfectly maintained as the exact UI element it should be.

> If there was a native widget that worked better than any of the current javascript-enhanced widget and could be styled to fit the website around it, lots of people would use it. Maybe not the top 50 web pages in world, but lots of developers with lower budgets would.

Awareness and training matter a lot here. There is now a usable <details> and <summary> element, but a number of people I know simply use bootstrap's data-toggle or a custom onclick handler because they don't actually know about the existence of these tags nor the gotchas you need to account for. Safari will have <datalist> support in the next major version, but I expect it will be a year or so before libraries begin to use it and developers won't use it until it is well documented and supported by libraries. The HTML spec introduced native attributes for a bunch of form states including valid/invalid state, required state, min/max values and more, but most libraries don't take advantage of them because they built the functionality before it had browser support and so developers don't use them either. We'll see these things gain adoption, but it will take time.

>1: Once they are in, you have to support them forever. Or you will break the few websites that use them.

That's not a problem. We want them supported forever. And basic widgets/controls haven't changed in substance since Xerox park or Win 3.1 anyway, so it's not like we'll discover suddenly that a autocomplete widget is a thing of the past.

>2: Almost nobody uses them. Try 10 popular websites and chances are you will not see a single native dropdown. You might not even see something as simple as a native radio button.

That's because they have been neglected (unlike the rest of the stack), and don't support extensive styling in most browsers.

I agree they are great but isn't most of the work in fetching & sorting the data? I can't see how this would work as a general widget.

In terms of the UI - I made a react component for showing dynamic suggestions (essentially a wrapper for downshift). And I've found the options out there for the sorting part quite good (e.g. match-sorter for sync or Elasticsearch completion suggester for async)

https://dan-kwiat.github.io/filter-suggest/

Yes, fill the web with keyloggers. It's best for the users.

It'd be your browser providing this. They already get all your keystrokes.

No mainstream browser sends arbitrary keystrokes back to their server.

If such an autocomplete widget becomes HTML standard it should be done through client-side information only. Knowing chrome though, they'd want to tie it to your "sync" identity which already autocompletes passwords/cc.

I don't understand. Currently the website I'm on and the browser get access to all my keystrokes. The suggestion is to allow an <input> tab to let the browser take over and do its thing for suggesting autocompletes (whatever that is) instead of the website suggesting them. What's the novel security concern?

Perhaps parent has turned off javascript?

Not more or less than a JS based autocomplete box does now. Possibly less, if more state is held locally.

Brilliant

Reply on news.ycombinator.com