HTML Data List Element(developer.mozilla.org)
developer.mozilla.org
HTML Data List Element
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/datalist
131 comments
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/
In practice, it's still hardly practical to use those, yet "regular" HTML has hardly evolved either.
[1] https://extensiblewebmanifesto.org/
How do web components[1] fail to be the custom elements you imagined?
[1] https://developer.mozilla.org/en-US/docs/Web/Web_Components
[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 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?
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.
- 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.
> 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="..." />`.
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.
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>
<better-datalist><!-- etc -></better-datalist>
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.
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.
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.
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).
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).
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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!)
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!)
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 :)
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.
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.
And today it's becoming common to see "best viewed in google chrome" or, worse, sites that are simply broken in Firefox.
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.
And we have … HTML with Java Applets and VB Script extensions
Do we? What browsers support java applets nowadays?
So those can work on iOS, Android, TV, Desktop, etc?
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.
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?
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.
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).
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.
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.
[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.
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.
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.
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.
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.
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 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.
It's a little different because I put the chosen selections on a row above the input row, but the principle is the same.
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.
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.
The datalist could work well with the range input, if that itself wasn't a dog's breakfast.
I suppose some experienced developer just found out that some interessting features have been added since 1996?
another, not that well known, tag which is IMHO quite useful when you have to serve static pages <base>[0].
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ba...
Edit: 1996 is just a random reference, not actually checked. Edit2: Link to English MDN.
another, not that well known, tag which is IMHO quite useful when you have to serve static pages <base>[0].
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ba...
Edit: 1996 is just a random reference, not actually checked. Edit2: Link to English MDN.
Sometimes those interesting features are not easy to find.
When looking up on how to do something for the web, one get tons of answers describing how to do it with javascript and usually with js frameworks. The simple methods (which do not cover all cases but are sometimes enough) are usually buried under.
So unless beginner learn by heart all the html tags (and that is not beginner friendly) they won't know those basic features, so I think that's cool to have a reminder.
When looking up on how to do something for the web, one get tons of answers describing how to do it with javascript and usually with js frameworks. The simple methods (which do not cover all cases but are sometimes enough) are usually buried under.
So unless beginner learn by heart all the html tags (and that is not beginner friendly) they won't know those basic features, so I think that's cool to have a reminder.
Yeah, I didn't now about data-* attributes until about two years ago. I quickly leveraged it to make creating forms with branching less of hassle: instead of relying on complicated state to hide and show different divs, I simply used data-next and data-previous attributes to govern navigation through the tree.
When you say branching, are you talking about a dynamic input, e.g., an email text input that appears after a subscribe checkbox is selected?
When there are dependencies between questions in a form (e.g. only ask for date married if answered yes to married). Its confusing if those elements are visible when not needed, so yeah, becomes dynamic.
Also, I used "tree" loosely. I meant something closer to a DAG.
Also, I used "tree" loosely. I meant something closer to a DAG.
Absolutly, that was exact the feeling when i realised that datalist exist. How on earth could i miss that?
The Internet is getting more and more "sources", but all of them seem to be almost direct copies of already existing source of information, just with a different layout.
The Internet is getting more and more "sources", but all of them seem to be almost direct copies of already existing source of information, just with a different layout.
I'm not a fan of the whole WHATWG spec/process, but it has datalist and other not-so-well-known elements covered. If you prefer a succinct reference (rather than the full browser-melting spec), there are other other sources than WHATWG's spec or MDN helping with discoverability, such as mine (as a proper SGML DTD grammar, no less) [1].
[1]: <http://sgmljs.net/docs/w3c-html52-dtd.html>
[1]: <http://sgmljs.net/docs/w3c-html52-dtd.html>
I absolutely hate the web dev community. Any HTML or JS related question was answered by "just use jquery" for maybe a decade.
The jQuery cliche was such a meme: https://imgur.com/Q3mkcnl.gif
Just used `base` today: building a whole reporting framework that needs to work from static files, and base is one of those little tricks that makes it all nicer.
I am hitting a lot of weird little things running from static files, but I think it helps me quite a bit that I know html from when it was young -- hand crafting html for your angelfire site in the 1990's sort of prepared me for semantic tags...
I am hitting a lot of weird little things running from static files, but I think it helps me quite a bit that I know html from when it was young -- hand crafting html for your angelfire site in the 1990's sort of prepared me for semantic tags...
uh, missed that. Thanks.
Most of the web seems like the devs are stuck in the early 2000s just with faster computers.
I think part of it is stack overflow where 15 years ago the only way to do a lot of stuff was a couple functions full of jquery so that's what the "correct" answers say to do.
I think part of it is stack overflow where 15 years ago the only way to do a lot of stuff was a couple functions full of jquery so that's what the "correct" answers say to do.
I'm running Firefox on Android and it doesn't seem to behave any different from a plain text input - no suggestions aside from the keyboard's predictions, and those are mostly things that aren't in the list.
Chrome on Android shows the list of suggestions as soon as the element is focused, and typing filters it as expected.
Chrome on Android shows the list of suggestions as soon as the element is focused, and typing filters it as expected.
That's a bug in Firefox for Android that's being tracked https://bugzil.la/1535985
It's a bug in Firefox, and affects the Windows version, not just Android.
It's the worst sort of invisible and undiscoverable UI bug: clicking on the left/middle of the box is interpreted as wanting to do text input (with no menu of choices to select from), while clicking on the right end activates an apparently invisible "pull-down arrow" that will show you the list of allowable choices. Yuck!
It's the worst sort of invisible and undiscoverable UI bug: clicking on the left/middle of the box is interpreted as wanting to do text input (with no menu of choices to select from), while clicking on the right end activates an apparently invisible "pull-down arrow" that will show you the list of allowable choices. Yuck!
I'm using a browser based on Chromium 83, and it's the same story.
I would not rely on this element for another 20 years or so.
I would not rely on this element for another 20 years or so.
Having made websites since 2004, I was very mindblown when I found out about this a few months ago.
Having tried it out, I was very mindblown at the several basic usability problems and lack of customizability, meaning I can never use it. Don't understand how this made it all the way into browsers.
It's strange how there's this large gap between what developers need and what ends up in the browser. It's a lot better than it was though.
Having tried it out, I was very mindblown at the several basic usability problems and lack of customizability, meaning I can never use it. Don't understand how this made it all the way into browsers.
It's strange how there's this large gap between what developers need and what ends up in the browser. It's a lot better than it was though.
I wish the options for the datalist behaved the same way as selection options, where you can separate the values from the labels.
Every major browser has different behavior. Chrome shows the child(label) and value, Firefox shows the child, and Edge shows the value.
Every major browser has different behavior. Chrome shows the child(label) and value, Firefox shows the child, and Edge shows the value.
It's a confusing element. When you click, it opens a dropdown of elements giving a feel of a normal <select> element. But once you select an element you can't change it unless you delete what you have selected.
The main problem with datalists are that browsers tried to work around them with autocomplete which overlay on top of the datalist. Ridiculous situation.
You can set the attribute autocomplete=“off” on the corresponding <input> in order to prevent this from happening. See the relevant MDN page for more details: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes...
I'm still waiting for a proper combo box out of HTML <input>. We're still stuck with Win16 style pairing of an input box with a select list underneath it.
I don't like that this relies on globally unique ids to link elements. I would prefer the ability to specify some kind of relative path instead. (there are similar problems in other areas, like aria)
This is a general problem with HTML5. I end up having to write some kind of autoincrementIdCounter function in every frontend templating language I use to work around it. I wish it was on W3C's radar as a thing that makes life harder for developers.
Yeah it's kind of awkward. My first assumption would have been that it would have had semantic similarities to a `<select>`, ie
<input type="datalist">
<option>a</option>
</input><input> has been an empty element right from the start, meaning it mustn’t have any children. (And the HTML syntax enforces this.)
AFAIK <input> is hardcoded as self-closing in the html5 parser.
Hm interesting... presumably this could be changed though? We aren't locked to <input> following one convention, are we?
Every linked element relies on ids: anchors, the label for attribute, all of the aria-labelledby, controls, describedby etc. Sure a full selector would be better but what level of css selectors do you support when writing the spec for user agents to know that can support the element?
Interesting, on iOS it uses the predictive text thing above the keyboard to display the options
And sadly it doesn't update during typing (at least last time I checked in 14.x). I developed a quick PoC autocomplete for a language that has no support which updated datalist with word predictions. Works beautifully on Android but not on iOS.
Seems to be updating as I type for me
Yeah! Just tested on 14.6 and 15 and it's working fine.
It would have been good to have a way of defining a method that can return the values instead of pointing to a static list. Also, perhaps a way of having a method for handling the display via a method and/or div.
example: <input list="ice-cream-flavors" id="ice-cream-choice" match="findMatch()" displayMatches="displayMatches()" name="ice-cream-choice" />
<div id="match"> <label>{match.id}</label> <img src="{match.imageUrl}"/> <p>{match.value}</p> </div>
But then HTML itself would need to have a templating syntax which works on data including having the ability to do conditional branching, looping, pattern matching etc... which may not have been a bad idea. But then you may be reinventing javascript :)
example: <input list="ice-cream-flavors" id="ice-cream-choice" match="findMatch()" displayMatches="displayMatches()" name="ice-cream-choice" />
<div id="match"> <label>{match.id}</label> <img src="{match.imageUrl}"/> <p>{match.value}</p> </div>
But then HTML itself would need to have a templating syntax which works on data including having the ability to do conditional branching, looping, pattern matching etc... which may not have been a bad idea. But then you may be reinventing javascript :)
This is nice, but it doesn't indicate the field is clickable or is a list, which could be done by always showing the chevron which currently shows up on hover. This can probably be done on CSS level, though.
And actually that chevron bit doesn't show on firefox apparently. I had to click in and press the down arrow to see the list. Otherwise it appears like its just a blank input field to me.
It has a chevron to indicate options when the input is focused as well as when the user hovers over it so there's no reliance on a mouse input. That seems to be enough to me. Why would the user need to see a chevron all the time, eg even when they're not interacting with the element?
It's needed when they're using a modern touchscreen computer instead of an ancient mouse-driven one, like I did when reading the link from this post this morning (Surface Pro undocked, so no keyboard). There is no clue the pull-down is even there otherwise!
To know they can interact with it.
If the field is optional they might just skip it to not type.
Not everyone can hover over it.
If the field is optional they might just skip it to not type.
Not everyone can hover over it.
For the developers here claiming about the severe lack of features (bolding fuzzy search matches, etc.), is this addressable through extending the default element through something like Lit or Stencil?
I'm hopeful that my team's design system can utilize/inherit a majority of the standard components and extend their functionality without a complete rewrite being necessary.
I'm hopeful that my team's design system can utilize/inherit a majority of the standard components and extend their functionality without a complete rewrite being necessary.
Acts like a normal input on Android Firefox for me
How have I never heard of this! It's like a native autocomplete-like select box. These are usually implemented in JS...
Also seems to be [1] widely supported with around 95% of all internet browsers supporting it.
[1] https://caniuse.com/datalist
Also seems to be [1] widely supported with around 95% of all internet browsers supporting it.
[1] https://caniuse.com/datalist
Unfortunately, it's not that good. There are a lot of strange and inconsistent behaviors related to this tag. That's why nobody uses it, and that's why you've never heard of it.
Imo, it's only suitable for ultra-narrow use cases, mostly prototyping.
Imo, it's only suitable for ultra-narrow use cases, mostly prototyping.
If people start using it maybe it will get some love.
I felt the same way when I discovered this element about a year ago. Each time I try to use it I always find it falling short of what I need it to do. It's incredibly limited in what can be styled with CSS, doesn't have the ability to have multiple values and there is no max-height to the dropdown. I've seen the dropdown grow so large it clips out of the browser itself - which might have been a bug that is now resolved.
This is a old UI element and I have been using it a lot
Just curios how it became top in HN ?
Just curios how it became top in HN ?
Probably because after all the time it's been around it still has some issues preventing wider usage, such as not working well in Firefox Android and lack of much customizability. Hopefully the increased publicity will help with some of this.
Someone, or maybe a lot of people, must have failed an interview. Speaking from experience.
How is it different from <select>? Or is it so that you can enter a value OR select a premade list?
I don't know if it's related to the way my browser implements it, but with <datalist> once I've picked an item it's then the only one that appears if I click again on the arrow to list the options. That's not the case with <select>, which _always_ lists all available choices regardless of the one currently selected.
I can see this being confusing, and someone wondering where all the options went. They come back if you click to edit and then manually delete the text, but not everyone will think of it.
The auto-complete feature is nice and <datalist> supports custom values that aren't in the preset list, but if you have a specific list of options and only want to allow those then it seems like <select> would be more appropriate.
I can see this being confusing, and someone wondering where all the options went. They come back if you click to edit and then manually delete the text, but not everyone will think of it.
The auto-complete feature is nice and <datalist> supports custom values that aren't in the preset list, but if you have a specific list of options and only want to allow those then it seems like <select> would be more appropriate.
if you write "lla" it gives you Vanilla, as opposed to a select which will require you to type "v"
My understanding is that is the combination of both a standard <input> and <select>. You can either choose one of the pre-defined options from the dropdown or add your own custom value in the input.
I've tried hard to use this element on many applications but each time I always find it falling short of what I need it to do so I just end up creating a custom element. My biggest gripes are the lack of a max height attribute for the dropdown and inability to do much in terms of CSS styling. It would also be pretty slick if it was possible to select multiple values.
I've tried hard to use this element on many applications but each time I always find it falling short of what I need it to do so I just end up creating a custom element. My biggest gripes are the lack of a max height attribute for the dropdown and inability to do much in terms of CSS styling. It would also be pretty slick if it was possible to select multiple values.
I will continue to use MaterialUI's Autocomplete.
Doesn't seem to work on Firefox Android for me
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.