3 ms·

> The native HTML <dialog> element should be used in creating modal dialogs as it provides usability and accessibility features that must be replicated if using

> The native HTML <dialog> element should be used in creating modal dialogs as it provides usability and accessibility features that must be replicated if using other elements for a similar purpose. Use the appropriate .showModal() or .show() method to render dialogs. If creating a custom dialog implementation, ensure all expected default behaviors are supported and proper labeling recommendations are followed. Any bets how long it will take JS frameworks to catch up to default behavior? Many websites still do not manage to properly make the back and forward button work, even after years. I am glad, that more semantic elements made it into HTML, reducing the amount of stuff needed to make simple things. I only wish, that we used the standard more.

pier25 4y ago
> Many websites still do not manage to properly make the back and forward button work, even after years. Yeah. Many (most?) JS client-side routers don't allow you to change the URL without reloading the current route, reset scroll, etc. I started working on a toy router for Svelte precisely to fix this behavior. https://github.com/PierBover/roots-svelte-router https://github.com/PierBover/roots-svelte-router The project is abandoned though. I lost interest in client-side routing and focused on fullstack (SSR + hydration).
cush 4y ago
Like most things in the js ecosystem, it likely never will. It'll be a best effort, chasing the standard with usability and accessibility gaps littering even the best libraries. But hey, there's rounded corners that glow, so totally worth it.
- interstice 4y ago
  Those libraries often cover edge cases the spec doesn't. For example with this what if for some reason I need the top level to share a some permamently available UI element?
  - ddulaney 4y ago
    Just use iframes! But more seriously, you do this in multi-page apps by just having that UI element in every page. Just about any (server-side) templating system lets you do that easily.
    - interstice 4y ago
      Sure, but is <dialog> going to work seamlessly with that if it isn't aware of positioning outside of the top layer? It could be that it is, but this is just an example of the kind of relatively common case that these maligned libraries cover that the spec often doesn't acknowledge.
lenkite 4y ago
The big problem is that default styling for the "semantic" HTML form elements still seems stuck for a CRT desktop display of the 90s. Why, oh-why, can't browser vendors update the default styling for modern devices ?
- another-dave 4y ago
  Completely agree. If we had HTML elements as stylable as CSS toolkits out of the box, we'd save a lot of HTML bloat, and there would be no reason that the styled versions wouldn't be keyboard navigable, support screen readers etc. Looking at stuff like date picker at the moment, it's just not going to get used at all as-is.
lloydatkinson 4y ago
> Any bets how long it will take JS frameworks to catch up to default behavior? What does this even mean? I can write a component in any JS framework that uses the dialog element literally today.

pier25 4y ago

> Many websites still do not manage to properly make the back and forward button work, even after years. Yeah. Many (most?) JS client-side routers don't allow you to change the URL without reloading the current route, reset scroll, etc. I started working on a toy router for Svelte precisely to fix this behavior. https://github.com/PierBover/roots-svelte-router https://github.com/PierBover/roots-svelte-router The project is abandoned though. I lost interest in client-side routing and focused on fullstack (SSR + hydration).

cush 4y ago

Like most things in the js ecosystem, it likely never will. It'll be a best effort, chasing the standard with usability and accessibility gaps littering even the best libraries. But hey, there's rounded corners that glow, so totally worth it.

interstice 4y ago
Those libraries often cover edge cases the spec doesn't. For example with this what if for some reason I need the top level to share a some permamently available UI element?
- ddulaney 4y ago
  Just use iframes! But more seriously, you do this in multi-page apps by just having that UI element in every page. Just about any (server-side) templating system lets you do that easily.
  - interstice 4y ago
    Sure, but is <dialog> going to work seamlessly with that if it isn't aware of positioning outside of the top layer? It could be that it is, but this is just an example of the kind of relatively common case that these maligned libraries cover that the spec often doesn't acknowledge.

lenkite 4y ago

The big problem is that default styling for the "semantic" HTML form elements still seems stuck for a CRT desktop display of the 90s. Why, oh-why, can't browser vendors update the default styling for modern devices ?

another-dave 4y ago
Completely agree. If we had HTML elements as stylable as CSS toolkits out of the box, we'd save a lot of HTML bloat, and there would be no reason that the styled versions wouldn't be keyboard navigable, support screen readers etc. Looking at stuff like date picker at the moment, it's just not going to get used at all as-is.

lloydatkinson 4y ago

> Any bets how long it will take JS frameworks to catch up to default behavior? What does this even mean? I can write a component in any JS framework that uses the dialog element literally today.