alt Hacker Newssince the author brought up the native <dialog>, developers chose custom implementations of dialogs because they want better accessibility, better focus management, better mobile and touch screen reader support, and more flexibility. adobe's implementation is far more robust and flexible compared to the native dialog, and it's hard to justify "use the platform" when it results in a strictly worse end result.
Replies
uhoh-itsmaciek • today at 4:49 AM
Yeah, that was kind of ignored in the article and it's definitely an issue for some platform features. Date pickers are another one where it's easy to outgrow the native implementation.
➕ show 1 reply
When I tried using <dialog> for the first time, there was one major thing that stuck out to me as a bit of a problem with how it is implemented:
It has become a norm to expect that if you click/tap on the backdrop of a modal/dialog, it will dismiss the modal/dialog. That isn't the case with <dialog> by default, and you need to use either use a hacky JS handler that checks the bounding box of the dialog (because the backdrop click events just end up fed to the dialog element), or use an attribute, `closedby`='any' that does not work on iOS and has spotty support at best in desktop Safari