https://jsfiddle.net/46nha7v3/
I enjoy native elements when they are there. You can do really nice interactive trees with the <details> element for example:
https://twitter.com/marekgibney/status/1593950777739218947
But I am not sure if it is a good idea to bake more and more of them into the browsers. Couldn't well made JavaScript modules provide the same functionality without making browsers more and more complex?
They're halfway to what you want but can't go further because everyone has slightly different needs and browsers are already complex enough without baking in prebuilt components for everything from data tables to carousels to modals to drop-down menus.
Also, the list of things that bug you that a language needs describes pretty much every programming language in existence.
The bit about ecosystem and the context on JavaScript makes me certain he meant external needs - in other words he'd like "batteries to be included". There are several languages that come with a lot of stuff out of the box.
body:has(dialog[open]) {
overflow: hidden
}
body:has(dialog[open])::before {
content: "";
position: fixed;
top: 0;
left: 0;
width: 100%;
height: 100%;
backdrop-filter: blur(4px);
background-color: rgb(0, 0, 0, 0.5);
}Here in Firefox, it does not work.
https://jsfiddle.net/t34wz6kx/
Also, using "position: fixed" will fail when the dialog is longer than the screen. Then the user cannot read it all, and if the close button is at the bottom, they cannot close it.
There's some more information on MDN [0] about how to make a modal dialog, you can open one in JavaScript using showModal() which has a backdrop, is actually modal, etc.
[0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
https://jsfiddle.net/5gevzft8/1/
Looks like you cannot use a button in the dialog then though. As it somehow makes the dialog scroll to the bottom.
My understanding is that you should be doing two things here: firstly, dialogs shouldn't generally be scrollable by themselves (or if they are, the interaction buttons should be sticky so that they're always visible). Instead, if you've got long text (say T&Cs) that should be in a scrollable box of its own. This allows the user to see the whole dialog (interactions and all) at once. Secondly, if there is something that should take focus before the buttons do, then you should set autofocus on that element explicitly. So in this case, you'd wrap the long text in a scrollable div, and add an "autofocus" attribute to that div to ensure that keyboard based users will immediately jump to it and be able to scroll it with their keyboard.
Prebuilt, specific components should focus on providing utility for documents and forms.
The “details” tag is a good example. It has interactive utility, clear semantics, but is easily extensible and you can fully style it.
The text input tag, not so much. It’s for example difficult to extend into a typeahead/combobox with sensible UX and presentation without writing a whole buch of JS. And the story around accessibility isn’t clear either.