Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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



> 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

The project is abandoned though. I lost interest in client-side routing and focused on fullstack (SSR + hydration).


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 ?


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.


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.


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?


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.


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.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: