Hacker News Reader

Comment by montroser | Hacker News Reader

The <datalist> element tries to address a common use case: it provides an autocomplete-enabled input so that as the user types, they see a filtered list of valid options.

It's great for prototyping, but its extensibility is so limited that it's not actually useful for real production applications. For example, you can't bold the parts of the options in the dropdown that match the input the user has entered in the text box. You can't add images or other rich content in the options. You can't style the dropdown itself. You can't do fuzzy matching. You can't receive events as the user keyboard-navigates through options...

It's a shame, since it's not a bad start, but users expect more than what <datalist> provides, and so we always have to go with a custom solution.

View on HN

Autocomplete should have been part of HTML 20 years ago. It's incredibly frustrating how slow HTML moves when it comes to basic usability.

Most painful is that the idea was [1] that the web would be extended with the ability to create your own custom elements so that we would no longer have to wait on web standards to evolve.

In practice, it's still hardly practical to use those, yet "regular" HTML has hardly evolved either.

[1] https://extensiblewebmanifesto.org/

> so that we would no longer have to wait on web standards to evolve

Isn't that exactly what we have today? I want a better <select> element, I drop in Select2. I want modals, I use Bootstrap modal. And so on. Particularly with libraries like React and Vue, where we literally type `<autocomplete options="..." />`.

I mean, sure, but we've always had that - but having widely-supported elements that are as good as the built-in elements with accessibility support and all, and have no dependencies and no requirements on a particular application architecture or framework use would certainly be nice.

I’m not sure I understand what you’re thinking of. If it’s native to one browser, then usage is restricted. To allow different browsers to use it means standards like we already have. JavaScript is the means by which websites can augment the browser with their own functionality - dependencies make it easier for developers to do this, but are not necessary. Plugins allow users to do the same.

I can’t think how it could work differently.

It means standards like were newly developed under the Web Components umbrella. The idea was that you could do something like

    <script type="html" src="better-datalist.html>

and then you'd be able to use e.g.

    <better-datalist><!-- etc -></better-datalist>

regardless of whether you're using one framework or another, and without adding heaps to your payload.

So the browser comes with opt-in native controls that a page can enable. Is that right?

What happens if the component is not available at runtime? Or if browser implementations ar inconsistent? It seems to me that these are the main constraints, rather than release of new standards.

Not quite; you (or rather, third parties properly maintaining them) can define your own components (i.e. in `better-datalist.html`) that you would then be able to use.

But yes, there are indeed a number of limitations with that approach that result in this not being a widespread practice yet. An alternative would have been if some of the remaining elements people need would have been standardised and implemented (consistently and widespread, of course, like other standards nowadays) by browsers, but that hasn't happened either. Which means we're still dependent on framework-specific, incomplete non-standard implementations.

How do web components[1] fail to be the custom elements you imagined?

[1] https://developer.mozilla.org/en-US/docs/Web/Web_Components

It is what Web Components were supposed to be, but they're not living up to that yet. They're reliant on client-side JavaScript, have special needs that cause them not to be well-integrated in the most widely-used JS framework yet, and have a number of other issues - as evidenced by the fact that there's still not a custom element that basically solves the mentioned limitations of Data Lists and is widely used and can be counted on to be as well-done as native elements in areas like accessibility.

I partially blame those who were trying to repurpose them as an application architecture framework, but primarily it's just a hard problem to solve.

Which is fine, but it's a shame that at the same time there's been practically no progress on the actually built-in elements, especially when you compare it to e.g. the amount of progress that's been made in JavaScript.

I'm probably ignorant: is there an example of any kind of custom element, in 2012 or now, with customization (nevermind CSS styling) that does not depend on JavaScript?

No, that's one of their limitations. (Well, styling can be done to some extent with CSS variables and the shadow DOM, I think.)

Ok, so as someone new-ish to web programming, how should I understand the current relevance of 2012's Extensible Web Manifesto, and the dissatisfaction you're expressing about <datalist> and about Web Components?

I'm sure it's due to a failure of imagination, maybe my own or maybe more widespread, but I don't actually know what you'd rather have, since it seems that there is still no concrete (even experimental) prototypes for kind of custom elements that you're envisioning. What am I missing?

So I'd prefer either:

- built-in elements that cover common elements like autocompletes or typeahead elements that allow e.g. the inclusion of images and formatting with their suggestions, or

- custom elements to work well enough in practice that those elements would have been created by third parties and would be widely used now.

I don't know whether the latter is actually possible, but I'm lamenting the fact that a focus on that goal seems to have coincided with hardly any attention being given to the former.

Sortable tables should have been in 1.0, too.

I'm not sure adding more concrete UI elements is the way to go, browsers are too complex as at is, which makes it extremely hard to develop them unless you have as much resources as Google. And what happens after 10 years when new UI trends become popular and we need new ui elements? We don't want to break the web, we can't just remove old stuff, so we'll need to keep adding and adding.

I think a much more important endeavour is to make the browser more extensible,(like what CSS Houdini is trying to do), so you can create any kind of crazy interfaces(without having to abandon css/html completely and drop down to canvas/webgl).

Fields with autocomplete have been around for decades. By having them in a spec, we don't have to reinvent the UI element poorly on every single site.

I just don't think browsers are in a good position to implement advanced features like this, though. They are too general of a tool to be opinionated and if you aren't going to be opinionated I don't see how javascript isn't the answer.

What kind of autocomplete do you want? Which algorithm? What's the threshold if you're using some kind of "string distance" metric? What do you want to do style wise when you match portions of strings? What optimizations should be made for your specific case?

I don't see how a web browser is in a better position to make these types of features compared to a javascript library / web assembly.

It’s complicated but we did used to have people doing all sorts of nasty tricks with images to style checkboxes and stuff.

I think some attempts at incremental improvement would be nice, maybe as the drop down gained usage that would help decide it’s future direction. Right now it’s just kinda dead and hard to use unless you’re building developer UI or something.

All autocomplete implementations has different behaviour. It is not as basic as other fields such as text and checkbox. The same applies to date input which still often have custom implementations because the browser based input has ux issues or offers limited behaviour changes.

> And what happens after 10 years when new UI trends become popular and we need new ui elements?

Design trends change, but the basic components that make up form elements have remained the same. We still have buttons, text fields, check boxes, radio buttons, etc. Those aren't going anywhere.

Well, depends on if your consider a slider a check box and a sequence of rows of which one is highlighted a radio button.

I keep coming back to the idea that HTML needs to phase out making way for a modern rendering language.

Then when I start thinking about what that would mean I realize it's almost always going to be an evolution not a revolution for the following reasons...

1) No one wants to deliver two UIs, one for HTML legacy browsers, and one for the hot new browser rendering.

2) Who would own the standards? If it's a consortium we'll be back to lengthy RFPs and glacier pace of agreement, possibly resulting in something worse than HTML that does not get adopted. I can't see how any one organization could own the standard and get other browser developers to buy into it.

HTML+CSS is so integral to everyday life it's hard to see how it could ever be deprecated.

I believe it could be replaced by a platform agnostic language for describing interfaces. Imagine a universal standard for representing data on screen, where each platform could differentiate by building their specific abstractions on top of it.

And we have … HTML with Java Applets and VB Script extensions

So those can work on iOS, Android, TV, Desktop, etc?

Do we? What browsers support java applets nowadays?

Isnt that exactly what HTML is?

Not exactly, no. It can be rendered on any operating system, but it is not the rendering language used for all platforms. What I'm talking about is all platforms (web, ios, android, tv, etc etc) using a single standard for representing interfaces. Similar to what happened to network technologies in the 80's and 90's, where all the competing silos agreed to use the http standard.

What I'm proposing is drastic and radical, but consider how insanely expensive it is to create a multi-platform application. Currently all efforts to bridge the gap between platforms sits at the application layer - flutter, react native, electron, etc. It's a massive effort to build an abstraction on top of each of these platforms, because the only common denominator between them is at the OpenGL layer. I think the common layer should be a couple of abstraction layers higher.

> It can be rendered on any operating system, but it is not the rendering language used for all platforms.

We could have this right now if iOS, Android, TVs, Windows, macOS, Linux, etc. all used HTML+CSS instead of their own toolkits. Yet they don't. Creating some fancy alternative is an even harder problem, since (a) that alternative needs to be designed and built and (b) all those same platforms will still need to switch, except we would also have to switch over the Web too.

This is a political issue, not a technology issue: it requires convincing a whole bunch of organisations to perform a costly change, for little direct benefit to them.

This would also be very easy to abuse via "embrace, extend, extinguish". Consider the history of word processors: everyone used the de facto standard (Lotus Notes) for compatibility. When Rich Text Format came along, underdogs like Word could read and write Notes-compatible documents. Once Word's market share rose, Microsoft "extended" the format so its documents could no longer be read reliably by Notes. Customers then switched to Word since it was "more reliable" at reading documents (i.e. it could handle the valid files produced by Notes, as well as the broken junk that Word produced).

Of course, Microsoft tried the same thing with HTML (badges like "Best viewed in Internet Explorer" became common precisely because IE did things in an incompatible way; I remember the relief among Web devs when IE7 came out, at its slight move towards compatibility!)

And today it's becoming common to see "best viewed in google chrome" or, worse, sites that are simply broken in Firefox.

Interesting! Although I wonder if similar conditions existed with networks in the 80's - I don't know much about the period but I do know there was competition. I'd be curious to know how http succeeded in that environment, because all the factors you listed should have killed it as well.

TCP/IP faced a lot of competition (e.g. from token rings), but won out probably due to simplicity and robustness.

The current dominance of HTTP is largely due to firewalls, NAT, and possibly developer familiarity (e.g. proxying, debugging via cURL, etc.).

I wasn't online in the 80s, but I remember networking in the 90s being a mixture of HTTP, POP, SMTP, IRC, FTP, Telnet, NNTP, etc. The noughties saw an increase in protocols for P2P, instant messengers, etc. These days those seem to have consolidated (e.g. BitTorrent, XMPP, etc.), are often tunneled through HTTP, or are displaced by something newer which tends to use HTTP.

I think you're confusing something, Lotus Notes was not a word processor. In USA, the most popular word processor before MS Word was WordPerfect.

Ah thanks; I know Lotus was popular, but was probably thinking of Lotus 123 versus Excel. The main point still stands though :)

My expectation is that we're going to move away from the hard link between data and UI some day.

Services will simply offer their data with an API (and micro-transactions to use it), and then 3rd parties will create UI's for each interface.

Tweets are a useful data type, but there's nothing about twitter's brand UI that is necessary.

Why would any company give up their data and brand awareness? Twitter exists to sell advertising -- their brand UI is 100% necessary. More necessary than the data itself.

Well, it's not like <datalist> was only just added. It's been in browsers for over a decade. It was in Firefox 4. Even IE10 supported datalist.

> Autocomplete should have been part of HTML 20 years ago

Isn't autocomplete a function of the browser, not of the markup?

Browsers have Autocomplete for previously inputted things, but many websites want Autocomplete for partial queries that the user hasn't typed before

The web has moved on to doing "everything" with JS.

It's almost like complaining that, darn it, Windows .rc files should specify every behavior of a control, not just a few basic properties; why do we have to write custom widgets using numerous Win32 API calls and event handling cases?

I think a lot of people think that HTML Elements === HTML Code, but they don't. JS and HTML are just two different ways of telling the browser how to build a DOM.

And depending on what you're doing, either can be more efficient than the other.

Being able to extend native widgets with custom behaviors could help make things much more elegant, though—such as augmenting in-browser autocomplete (to highlight search criteria, etc.) on top of already existing DOM with just a little extra JS, rather than putting together a completely bespoke one from a bunch of divs and a lot of code (counting third-party dependencies).

It would definitely be nice. That being said, I do think it'd make more sense to let people "roll their own" for at least a few years first. Just to get a really good idea of what the problem space is, and what defaults people are likely to expect.

I've seen a lot of projects try to set things up from the beginning without enough information, and it ends up falling a little flat (or worse, getting in the way).

A lot of things should have been part of HTML 20 years ago. Table sorting comes immediately to mind. No reason that should require JS for very straightforward cases, and almost none should need more than to define a sort function (or a few sort functions, given many columns), provided the table fits on one page. That's a no-brainer even if the web hadn't taken a turn to being the lowest-common-denominator app delivery platform. Given that's happened, there's a bunch more that should have been added, if not 20 years ago, certainly 10, to make it at least sort of resemble an actual GUI toolkit, in capabilities.

Every sortable table I have ever coded sourced it's data from a large database-backed data source. So sorting always requires a server call to fetch new data for the view.

In my opinion, a client-side only table sorting only solves a very small unlikely niche -- so small that's not worth doing.

Small and unlikely?! Wikipedia alone has thousands of them, and that's a safe, low guess. Probably tens of thousands. And there are lots of single-page tables on the Web that don't have sorting implemented, but that a user might wish to sort.

[EDIT] further, aside from that being a great feature for vanilla HTML even if it had continued to only be a document format, that's a great stepping stone on the way to having proper, datasource-backed tables, as is common in mature GUI widget frameworks and libraries.

What are the odds that the browser will be able to implement the one-size-fits-all sorting necessary to make the thousands of Wikipedia tables sort properly and look decent while doing it?

A browser-based implementation would be the lowest common denominator that would likely only be used when neither style or accuracy is required. Not unlike <datalist>.

I already replace every single browser form-field convenience with JavaScript/CSS based alternative that works better, looks better, and plays nicer with backend technologies. Implementing fully complete features in HTML seems like the wrong approach to me; I'd rather browsers provide the necessary low-level building to do it in code. It's much more future proof and flexible that way.

> What are the odds that the browser will be able to implement the one-size-fits-all sorting necessary to make the thousands of Wikipedia tables sort properly and look decent while doing it?

Approaching 1?

> I already replace every single browser form-field convenience with JavaScript/CSS based alternative that works better, looks better, and plays nicer with backend technologies. Implementing fully complete features in HTML seems like the wrong approach to me; I'd rather browsers provide the necessary low-level building to do it in code. It's much more future proof and flexible that way.

This is exactly the problem, if browsers are now our LCD GUI toolkits (and they are). You absolutely should not need to do that. The proof that this is feasible is present in... well, most other major GUI toolkits. The wasted time, wasted cycles, and broken features (especially, but not exclusively, a11y) due to HTML being so bad at being the thing we're trying to make it be are all avoidable problems, not hypothetically, but in fact.

All major GUI toolkits are customizable in just the same way -- with code. Desktop GUI toolkits don't auto-sort table data either -- you're still expected to code that.

Auto-sortability should have been there in HTML's capacity as a document format. All the hooks & interactive elements necessary for custom sorting with little more than a definition for a given column's sort function and some toggles for the various features, should be there now. It's absurd to have to start either by importing a library (which one? Why is this even a choice one must make?) or by leading with "OK, this th cell should have such-and-such onClick handler...."

If it were, we’d be stuck with 2000’s style autocomplete now.

You're also stuck with whatever you put in the option's value attribute - very unlike how a <select> works where the option has text content and a value.

Scenario: You've got customers, who have names and IDs. You want to search by name, but the ID needs to be sent to the server - you're right back to doing some JavaScript hack with a hidden field that gets a data-customerid attribute or whatever off of the selected option from a datalist.

It depends on the browser, but yes, it's a mess.

That actually sounds a lot like a <select>. If you need to have the customer ID, you won't be able to do much with just a customer name anyway. If you accept a name, you'd need to accept a separate ID too.

With select you have <option value="123">Customer Name</option> so the user sees Customer Name but submitting the form gets 123. With datalist you only have <option value="Customer Name"/> and the input tied to it gets Customer Name.

Yes. If you want to have the id, then why are you using a text input in the first place? This seems to be exactly the use case for a <select>.

For me, datalist is almost an acceptable compromise for a typical combobox (input + select/dropdown) control. Custom solutions for that require JS and are not accessible or otherwise don't behave as a user would expect a standard input to without lots of extra work.

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.

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

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 datalist could work well with the range input, if that itself wasn't a dog's breakfast.

Reply on news.ycombinator.com