3 ms·

Because HTML elements are forever while js modal libraries change yearly. It’s best for browsers to wait a few years and if there is one thing that has consiste

Because HTML elements are forever while js modal libraries change yearly. It’s best for browsers to wait a few years and if there is one thing that has consistently been used and will be forever, then add it. The details element is a good example. And even when we have an element, most devs end up replacing it with a JS version anyway. The HTML select element is a good example. The built in one almost always gets replaced with something that looks nicer and has more features like icon support and themeability

aikah 5y ago
> Because HTML elements are forever while js modal libraries change yearly. It’s best for browsers to wait a few years and if there is one thing that has consistently been used and will be forever, then add it. The details element is a good example. While I agree all these API need to be carefully crafted, this one is very much a no brainer. Mozilla (and Apple) should be at the forefront of these native UI improvements, because it allows the developer to rely on standard behavior rather than rolling out one's own broken UX. > And even when we have an element, most devs end up replacing it with a JS version anyway. No they don't. > The HTML select element is a good example Yes, because it's almost impossible to style it or make it display some custom content that isn't a line of text. The problem isn't its existence, it's its shortcomings because it was basically speced 25 years ago. I'll take a standard widget that I know will work in an expected fashion across many devices rather than someone's personal library in GitHub that is broken in subtle ways. That's the idea behind standards. I was on a site not long ago, which displayed a modal pop up, well the page was going up and down frenetically every half second because the developer probably used a library that wasn't tested on the browser I used. the UX was completely broken. With standards, if a polyfill is broken then you have a good argument to confront its developer with (if I can put it that way).
- foobar33333 5y ago
  >it was basically speced 25 years ago How do we fix it though? It clearly needs major changes and improvements, but those can't be made without breaking compatibility. Do we add a select2 element? modern-select?
  - brigandish 5y ago
    I'd plump for dropdown, if there really needs to be a new element. Not sure why options elements couldn't accept more attributes, they're easily ignored and don't affect the DOM tree. What's wrong with an icon attribute, for example, that points to an image? I don't know, but looking at the timeline for other features to be implemented that virtually (if not literally) every web dev has cried out for since year dot like vertical align and grid, I'm putting my money on a new select element around 2035.
deergomoo 5y ago
> The built in one almost always gets replaced with something that looks nicer and has more features like icon support and themeability Then why don’t we improve the capabilities of the built in one? I’ve always found this odd, JavaScript and CSS are constantly improving, and there’s a steady stream of new things to make development easier. But no-one seems to care about improving HTML, despite being by far the best focus of efforts. Rich functionality via new/improved HTML tags would be accessible, performant, would work without JavaScript, and in many cases could be easily polyfilled.

aikah 5y ago

> Because HTML elements are forever while js modal libraries change yearly. It’s best for browsers to wait a few years and if there is one thing that has consistently been used and will be forever, then add it. The details element is a good example. While I agree all these API need to be carefully crafted, this one is very much a no brainer. Mozilla (and Apple) should be at the forefront of these native UI improvements, because it allows the developer to rely on standard behavior rather than rolling out one's own broken UX. > And even when we have an element, most devs end up replacing it with a JS version anyway. No they don't. > The HTML select element is a good example Yes, because it's almost impossible to style it or make it display some custom content that isn't a line of text. The problem isn't its existence, it's its shortcomings because it was basically speced 25 years ago. I'll take a standard widget that I know will work in an expected fashion across many devices rather than someone's personal library in GitHub that is broken in subtle ways. That's the idea behind standards. I was on a site not long ago, which displayed a modal pop up, well the page was going up and down frenetically every half second because the developer probably used a library that wasn't tested on the browser I used. the UX was completely broken. With standards, if a polyfill is broken then you have a good argument to confront its developer with (if I can put it that way).

foobar33333 5y ago
>it was basically speced 25 years ago How do we fix it though? It clearly needs major changes and improvements, but those can't be made without breaking compatibility. Do we add a select2 element? modern-select?
- brigandish 5y ago
  I'd plump for dropdown, if there really needs to be a new element. Not sure why options elements couldn't accept more attributes, they're easily ignored and don't affect the DOM tree. What's wrong with an icon attribute, for example, that points to an image? I don't know, but looking at the timeline for other features to be implemented that virtually (if not literally) every web dev has cried out for since year dot like vertical align and grid, I'm putting my money on a new select element around 2035.

deergomoo 5y ago

> The built in one almost always gets replaced with something that looks nicer and has more features like icon support and themeability Then why don’t we improve the capabilities of the built in one? I’ve always found this odd, JavaScript and CSS are constantly improving, and there’s a steady stream of new things to make development easier. But no-one seems to care about improving HTML, despite being by far the best focus of efforts. Rich functionality via new/improved HTML tags would be accessible, performant, would work without JavaScript, and in many cases could be easily polyfilled.