4 ms·

Can you elaborate on <dialog>? It is currently implemented behind a feature flag in Firefox, and not implemented at all in Safari. So the answer with caniuse is

Can you elaborate on <dialog>? It is currently implemented behind a feature flag in Firefox, and not implemented at all in Safari. So the answer with caniuse is maybe with a polyfill. How exactly is it inaccessible at the core? As far as I know a <dialog> is required to have at least one focusable element inside it (I usually have a close button in the dialog’s <header>), and then the user agent is supposed to trap focus inside it. Is it not usable for users with assistive technology? Is it a bad UX for them? Is it broken or buggy? Does the polyfill not workk? etc.

fleddr 5y ago
Have a look at this: https://www.scottohara.me/blog/2019/03/05/open-dialog.html https://www.scottohara.me/blog/2019/03/05/open-dialog.html To sum it up, <dialog> is a specced standard of which the first implementation appeared 8 years ago. It is a perfect example to illustrate my original rant. It is a feature in high demand, almost every web application needs it. Hence it makes sense to have a native control and for each browser to implement it, eventually. No such thing happened. A broken implementation is delivered, and more importantly, never fixed. It doesn't work cross browser and in the browser where it works, it actually doesn't. And now, nothing happens, they just gave up on it. Which indeed leaves us with custom implementations, but my point is that we shouldn't need those. It was specced for a reason, it's high on the list of developers needs.
- jrochkind1 5y ago
  That is distressing. > tldr; I’m just going to say right now that the dialog element and its polyfill are not suitable for use in production. And it’s been that way since the dialog’s earliest implementation in Chrome, six-ish years ago. With the announced intent to get rid of window.alert/confirm (discussed elsewhere in this HN post comments), it would be nice if dialog got some attention as a replacement... I'm not sure what we're going to do when it goes away; everyone has to roll their own replacement? Doh.

fleddr 5y ago

Have a look at this: https://www.scottohara.me/blog/2019/03/05/open-dialog.html https://www.scottohara.me/blog/2019/03/05/open-dialog.html To sum it up, <dialog> is a specced standard of which the first implementation appeared 8 years ago. It is a perfect example to illustrate my original rant. It is a feature in high demand, almost every web application needs it. Hence it makes sense to have a native control and for each browser to implement it, eventually. No such thing happened. A broken implementation is delivered, and more importantly, never fixed. It doesn't work cross browser and in the browser where it works, it actually doesn't. And now, nothing happens, they just gave up on it. Which indeed leaves us with custom implementations, but my point is that we shouldn't need those. It was specced for a reason, it's high on the list of developers needs.

jrochkind1 5y ago
That is distressing. > tldr; I’m just going to say right now that the dialog element and its polyfill are not suitable for use in production. And it’s been that way since the dialog’s earliest implementation in Chrome, six-ish years ago. With the announced intent to get rid of window.alert/confirm (discussed elsewhere in this HN post comments), it would be nice if dialog got some attention as a replacement... I'm not sure what we're going to do when it goes away; everyone has to roll their own replacement? Doh.