HTML Data List Element
developer.mozilla.org
developer.mozilla.org
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.
In my opinion, a client-side only table sorting only solves a very small unlikely niche -- so small that's not worth doing.
[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.
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.
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.
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?
And depending on what you're doing, either can be more efficient than the other.
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 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).
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.
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.
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.
In practice, it's still hardly practical to use those, yet "regular" HTML has hardly evolved either.
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 can’t think how it could work differently.
<script type="html" src="better-datalist.html>
<better-datalist><!-- etc -></better-datalist>
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.
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.
[1] https://developer.mozilla.org/en-US/docs/Web/Web_Components
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 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?
- 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.
Isn't autocomplete a function of the browser, not of the markup?
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.
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.
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!)
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.
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.
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.
Meanwhile the browser default multiple select UI is still one of the shittiest UI widgets ever built and its still all we have.
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 the curse of complex UI elements on the web. Menu failed for similar reasons.
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.
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.
Also, I used "tree" loosely. I meant something closer to a DAG.
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 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 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...
Chrome on Android shows the list of suggestions as soon as the element is focused, and typing filters it as expected.
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 would not rely on this element for another 20 years or so.
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.
Every major browser has different behavior. Chrome shows the child(label) and value, Firefox shows the child, and Edge shows the value.
<input type="datalist">
<option>a</option>
</input>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 :)
If the field is optional they might just skip it to not type.
Not everyone can hover over it.
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.
Also seems to be [1] widely supported with around 95% of all internet browsers supporting it.
Imo, it's only suitable for ultra-narrow use cases, mostly prototyping.
Just curios how it became top in HN ?
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 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.