8 ms·

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

Vinnl 5y ago
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/ https://extensiblewebmanifesto.org/
- blowski 5y ago
  > 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="..." />`.
  - Vinnl 5y ago
    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.
    - blowski 5y ago
      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.
      - Vinnl 5y ago
        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.
        blowski 5y ago
        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.
        Vinnl 5y ago
        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.
- an1sotropy 5y ago
  How do web components[1] fail to be the custom elements you imagined? [1] https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components
  - Vinnl 5y ago
    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.
    - an1sotropy 5y ago
      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?
      - Vinnl 5y ago
        No, that's one of their limitations. (Well, styling can be done to some extent with CSS variables and the shadow DOM, I think.)
        an1sotropy 5y ago
        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?
BeFlatXIII 5y ago
Sortable tables should have been in 1.0, too.
Fatalist_ma 5y ago
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).
- arkitaip 5y ago
  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.
  - somethingAlex 5y ago
    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.
    - NegativeLatency 5y ago
      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.
  - 5y ago
monkeynotes 5y ago
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.
- tenaciousDaniel 5y ago
  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.
  - hestefisk 5y ago
    And we have … HTML with Java Applets and VB Script extensions
    - tenaciousDaniel 5y ago
      So those can work on iOS, Android, TV, Desktop, etc?
    - jamespo 5y ago
      Do we? What browsers support java applets nowadays?
  - madeofpalk 5y ago
    Isnt that exactly what HTML is?
    - 5y ago
adrianba 5y ago
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.
sneak 5y ago
> Autocomplete should have been part of HTML 20 years ago Isn't autocomplete a function of the browser, not of the markup?
- MarkyC4 5y ago
  Browsers have Autocomplete for previously inputted things, but many websites want Autocomplete for partial queries that the user hasn't typed before
kazinator 5y ago
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?
- seph-reed 5y ago
  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.
  - strogonoff 5y ago
    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).
    - seph-reed 5y ago
      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).
handrous 5y ago
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.
- wvenable 5y ago
  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.
  - handrous 5y ago
    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.
    - wvenable 5y ago
      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.
tinus_hn 5y ago
If it were, we’d be stuck with 2000’s style autocomplete now.

Vinnl 5y ago

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/ https://extensiblewebmanifesto.org/

blowski 5y ago
> 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="..." />`.
- Vinnl 5y ago
  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.
  - blowski 5y ago
    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.
    - Vinnl 5y ago
      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.
      - blowski 5y ago
        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.
        Vinnl 5y ago
        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.
an1sotropy 5y ago
How do web components[1] fail to be the custom elements you imagined? [1] https://developer.mozilla.org/en-US/docs/Web/Web_Components https://developer.mozilla.org/en-US/docs/Web/Web_Components
- Vinnl 5y ago
  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.
  - an1sotropy 5y ago
    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?
    - Vinnl 5y ago
      No, that's one of their limitations. (Well, styling can be done to some extent with CSS variables and the shadow DOM, I think.)
      - an1sotropy 5y ago
        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?

BeFlatXIII 5y ago

Sortable tables should have been in 1.0, too.

Fatalist_ma 5y ago

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).

arkitaip 5y ago
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.
- somethingAlex 5y ago
  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.
  - NegativeLatency 5y ago
    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.
- 5y ago

monkeynotes 5y ago

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.

tenaciousDaniel 5y ago
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.
- hestefisk 5y ago
  And we have … HTML with Java Applets and VB Script extensions
  - tenaciousDaniel 5y ago
    So those can work on iOS, Android, TV, Desktop, etc?
  - jamespo 5y ago
    Do we? What browsers support java applets nowadays?
- madeofpalk 5y ago
  Isnt that exactly what HTML is?
  - 5y ago

adrianba 5y ago

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.

sneak 5y ago

> Autocomplete should have been part of HTML 20 years ago Isn't autocomplete a function of the browser, not of the markup?

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

kazinator 5y ago

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?

seph-reed 5y ago
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.
- strogonoff 5y ago
  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).
  - seph-reed 5y ago
    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).

handrous 5y ago

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.

wvenable 5y ago
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.
- handrous 5y ago
  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.
  - wvenable 5y ago
    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.

tinus_hn 5y ago

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