<h2>FAQs</h2>
<details name="faq">
<summary>Why are interactive HTML elements cool?</summary>
They’re lightweight and semantic!
</details>
<details name="faq">
<summary>Will the previous answer close when I open this one?</summary>
Yes, because the <code><details></code> elements share the same name.
</details>
I started using <dialog> in 2019, even though Firefox and Safari wouldn't support it for another couple of years, but Google's own Polyfill (of which I am a very modest contributor) was top-notch quality and so I had no problems using it in production for my LoB SaaS day-job.
But my biggest let-down with the <dialog> element is that it's comnpletely unstyled, beyond a very basic (and very un-Chrome-like) thick black line pixel border with sharp edges. Whereas my-hope-and-expectation (and indeed: what got me interested in <dialog> in the first place) was that I was hoping that the browser itself would provide for a lot of the tedium involved in UI dialog dev-work in-general, especially for things like automaticallyt conforming to the host OS' conventions on dialog/window layout and placement: I was hoping that I could mark-up an actual semantic model of a dialog and the browser would do the hard-work of making it look like a real native macOS (or iOS) - or Windows - dialog resource.
I was also hoping that, because open <dialog> elements exist in a distinct top-level layer, that they might even able to escape the bounds of the browser viewport, which would provide real value to the end-user in a lot of places (e.g. no-one wants an unmovable popup or modal-dialog that completely obscures the user's view of an underlying document (like macOS's old "Sheets" dialogs) - so another false-hope of mine got popped that day.
-----
I get the feeling that browser vendors would all like to see us stop using `alert()`, `prompt()` and `confirm()` in JavaScript (because they block the JS/main thred), but the same browser-vendors really haven't come-up with an adequate replacement: the beeauty of alert/prompt/confirm is that their API is incredibly simple yet effective and also doesn't require the proggrammer to have any UI design-skills; I don't understand why browsers still don't offer a non-blocking Promie-based API for alert/prompt/confirm instead of them trying, in vain, to convince us that <dialog> is better in every situastion when it clearly isn't.
]
Premade ways of escaping the bounds of a browser viewport with styling like a system dialog box certainly sounds like something a developer would want rather than users or browser makers. It's not an accidental disappointment new things aren't made to function like alert() and friends used to, it also has upsides (beyond just "the old interface was not promise based".
I do agree <dialog> could have done with at least a little bit of TLC on the styling though, I just don't think it has to be 100% look and function like a system dialog outside the DOM to do it. Some base default styling to match the rest of the browser's default style would do wonders.
For PWAs (or any "web apps with more permissions than a random page should get just for being loaded") I could see where you wanted <dialogs> to go as a more well received idea though, similar to how there are separate things for styling the windows and interacting with the system for those more privileged pages.
Another reason might be that vendor making it look like a native browser window would blur the line of death[1]. It would make it easier for malicious website to make a popup "browser update" in the middle of the page that redirects to seemingly legit Chrome download page and downloads modified executable.
Modals that blocks focus to an entire browser window aren't really a good idea (I'm of the opinion that they are almost always a shitty idea, but that's harder to argue). People have multiple tabs open, and what if another tab contains information that your user needs to complete your dialog.
You also have to be incredibly careful about how much visual control you allow over an actual dialog - especially making it look like the host OS. People get bamboozled by shitty in-browser fake virus alerts all the time, now add a real dialog, with real looks, that the user is forced to interact with, and you have a slam-dunk.
this is what completely holds back most built-in browser components from widespread usage, i suspect the vendors implementing it just don't care at all because it's not their problem
every company i've ever worked at had at least a somewhat consistently defined design language and it would look completely amateurish and out of place to use built in browser components in most places, regardless of how much html/css purists want that to be the case
I've been playing around with the idea of alert() and prompt() and confirm() replacements that work like this:
await Prompts.alert("This is an alert message!");
const resultBoolean = await Prompts.confirm("Do you want to proceed?");
const name = await Prompts.prompt("What is your name?");
> I was also hoping that, because open <dialog> elements exist in a distinct top-level layer, that they might even able to escape the bounds of the browser viewport, which would provide real value to the end-user in a lot of places
And, within three seconds of release, a <dialog> with this ability would be misused by advertisers to bring back the old pop-up windows that all browser's block by default now, because of advertiser misuse.
Most websites have their own style they apply everywhere and would probably appreciate how styleable dialog is. Maybe a way to easily apply/remove default styles could satisfy everyone.
That's so different from my experience. When I first met <dialog>, I thought I understood its purpose (as a modal) was to block user input from reaching anywhere else on the page. I have no idea why would anyone want to use it non-modally, since you can just use a div for that.
Nevertheless, I was also let down by it because it turns out if your <body> has a scrollbar, scroll wheel events bubble. There is a CSS property to stop them from bubbling but it doesn't work!
> I was also hoping that, because open <dialog> elements exist in a distinct top-level layer, that they might even able to escape the bounds of the browser viewport, which would provide real value to the end-user in a lot of places
As a user, I would absolutely not want this. I appreciate being able to know which windows actually come from my browser and which are coming from a webpage.
> I was hoping that the browser itself would provide for a lot of the tedium involved in UI dialog dev-work in-general, especially for things like automaticallyt conforming to the host OS' conventions on dialog/window layout and placement
sadly this only reminds me of bad actors spoofing native dialog UI's to phish passwords and such
> the beauty of alert/prompt/confirm is that their API is incredibly simple yet effective and also doesn't require the proggrammer to have any UI design-skills
I’ve long hoped for more APIs in the style of alert/prompt/confirm, which are more like ready-made building blocks rather than cement to make cinderblocks with as most web APIs tend to be. Anything that helps cut down on the amount of HTML, CSS, and JS required to be written or imported would be a substantial QoL improvement. This does not seem to be a popular view, unfortunately.
I don't think anyone would say web-standards are excellent, well designed and well-managed.
All the wonderful value is in that they are standard. The web is great in its ubiquity. Love the web! Sure it's a mess, how could it not be?!
<dialog> is a win here in my view, especially for internal admin tools, I don't want to care about the latest flavor of frontend insanity. I just want to save screen space and open content as modal overlay on top of a main view.
>Last year the major web browser vendors decided to change the standard (remember, HTML is now a "living standard")
SIGH...
To be honest, I think it's unlikely you will ever try to open the same dialog modally twice. If you need user input to open the dialog, and a modal dialog blocks user input, the only way for this to happen is if you have an input on the dialog that opens the dialog. If you are using asynchronous tasks to open the dialog, then you probably should keep track of what is open and what is not.
The same thing would happen if you were doing it on Qt, for example.
I was really hoping the dialog element would end up as a customizable await confirm/prompt on steroids that wouldn't get flagged by every browser if you open it more than once. But it's more of a glorified div.
There's more where that came from. Google Chrome also did URLPattern, which I hope Chrome and Safari will hold firm on not supporting. The compression streams API wasn't bad, but it's a tiny API. I see a pattern here: Google sucks at UX and DX.
Edit: I looked up standards positions and both support URLPattern.
I love the <dialog> element, especially for its built-in / standardised accessibility considerations. I'm looking forward to the day I can roll it without a polyfill (once safari <15.4 drops out of our thresholds).
That said, my one major bugbear with it is the reliance on javascript. Yep, I expect all* users on my sites to arrive with JS enabled. But I also (selfishly?) derive some satisfaction from them not having to. Why can't I control the dialog's open state with CSS or a targeted button?
This is why I mainly use some other custom <div> with a popover="" attribute. They're easily targeted with a button and no clientside JS required, and can be closed by clicking outside them, which <dialog>s don't have by default. They also still have the same helpful top-layer properties.
Unsure about accessibility on this front, though it can't be worse than my previous attempts with hidden labels/checkboxes/form elements, while being much simpler and less hacky.
I wish HTML supported a concept of a "<PAGE>" tag which will allow multiple pages to be defined in a single HTML file and which can be shown one at a time but without the look-and-feel of a dialog.
Each PAGE should be able to pull in common sections from the same page such as the header, sidebar, footer etc based on specific states selectable in each PAGE.
Yes, you can do the same thing with the current approaches by hiding and showing divs etc.. But if it were possible to support these approaches via specific tags in HTML it may help.
Tried this today and came across an issue that I could not get around: if the dialog contains a form, then submitting the form with enter (focused on any input) or space (focused on the submit button) will close the dialog. I couldn't find any nice way of preventing it.
Normally a form will reload the page anyways so I guess this isn't a normal problem but I was using htmx.
I was unfortunately looking for a cookie consent manager for a new build I'd just optimized, and didn't like that the open source options were 100KB+ so I made my own [0] and relied on <dialog> to support my goal of writing it as small as possible. With a couple of CSS rules, it works natively without styles. I also ended up writing some build tools to compile all the way down to IE11 and some really ancient browser versions.
Dialog works well for the most part, with a couple of CSS kludges here and there for the older browsers but otherwise straightforward to deal with. It's a decent addition to the web platform, but after 20 years of this I would like to stop making custom multi select controls every couple of years. Native controls good.
For me it's the autofocus property on the close button that didn't work yesterday when I was using this in a project. Ended up adding a line to whenever I call show() like $('#thatModal *[autofocus]').focus()
MDN says this should work as intended out of the box
Could you elaborate on what you mean by "normal close in most examples"? All the examples I see come with a JS snippet to add an event listener to the close button and those work for me in Firefox for Android.
>Note: While you can toggle between the open and closed states of non-modal dialog boxes by toggling the presence of the open attribute, this approach is not recommended.
This perplexes me. Why is it not recommended? Why put it in a standard and then recommend against it? What's wrong with it? The documentation is silent.
Ublock origin is not able to filter out <dialog> elements without breaking scrolling and other buttons in most cases (depending on how the site is implemented). Is there a generic way to disable these without affecting the rest of the site?
Don't have a computer handy to try, but it can block elements right? What if you block simply dialog (without # or so, because it's not an ID but a tag name) on the desired domain?
Or a little userscript walking the DOM to find dialog elements and removes them. Or you could check if one can listen on them for show/open events, or hijack the show() method to do nothing
Lots of options I'd say
Not something I'd have in mind when using dialogs for legitimate purposes as a developer though. Don't wonder why you don't get my "do you really want to delete this item?" on my software when you block these altogether, but I guess you mean this for specific domains where it's used for ads (have yet to see dialog used for that, but no surprise that they'd exist)
I'm really glad you posted this 'htunnicliff', because I'm manually maintaining a 'stack' of Dialog elements, along with an associated full-bleed 'background' overlay to block mouse clicks outside the dialog, and it will be really nice if I can get this (dialog element) to work and replace my code with something simpler. I'm assuming dialog elements can overlay other dialog elements!! I'll try!
I still remember being confused about the differences between dialogs, popovers, and modal vs non-modal elements when I was first learning web development.
About two years year before <dialog> was rushed into all browsers, it had been implemented only in Chrome, and Chrome devs suggested removal of <dialog> completely. Reason? No consensus on multiple issues relating to accessibility and security: https://github.com/whatwg/html/pull/4184#issuecomment-440405...
And then boom! It was shipped everywhere with none of the issues discussed or fixed.
Why?
My tiny conspiracy theory is because browsers are hellbent on removing "legacy" APIs like confirm/prompt, and Chrome tried to remove it about half-a-year to a year before <dialog> was suddenly shipped everywhere: https://dev.to/richharris/stay-alert-d
I tried the stackblitz demo you linked to and I don't get it, why is "this element lets people author terrible user-hostile webpages" an indictment of the element? I mean you can make a user-hostile page with divs too. People won't be prevented from eg closing the tab, right?
I got an issue recently with how <dialog> interacts with AdSense “vignette” (interstitial) ads.
Vignettes set their `z-index` CSS property to the max (2147483647), but a <dialog> is still higher on the z-plane (with no way to adjust that).
So if you click a link from a <dialog>, and an interstitial gets displayed, it’s under the <dialog>. It looks like nothing happened, that clicking is broken.
Fix in my case was to close() the <dialog> onclick.
[+] [-] divbzero|1 year ago|reply
File pickers:
Color pickers: Date/time pickers: Numeric sliders: Suggested options for text fields: Summaries with expandable details: Media players with controls:[+] [-] DaiPlusPlus|1 year ago|reply
But my biggest let-down with the <dialog> element is that it's comnpletely unstyled, beyond a very basic (and very un-Chrome-like) thick black line pixel border with sharp edges. Whereas my-hope-and-expectation (and indeed: what got me interested in <dialog> in the first place) was that I was hoping that the browser itself would provide for a lot of the tedium involved in UI dialog dev-work in-general, especially for things like automaticallyt conforming to the host OS' conventions on dialog/window layout and placement: I was hoping that I could mark-up an actual semantic model of a dialog and the browser would do the hard-work of making it look like a real native macOS (or iOS) - or Windows - dialog resource.
I was also hoping that, because open <dialog> elements exist in a distinct top-level layer, that they might even able to escape the bounds of the browser viewport, which would provide real value to the end-user in a lot of places (e.g. no-one wants an unmovable popup or modal-dialog that completely obscures the user's view of an underlying document (like macOS's old "Sheets" dialogs) - so another false-hope of mine got popped that day.
-----
I get the feeling that browser vendors would all like to see us stop using `alert()`, `prompt()` and `confirm()` in JavaScript (because they block the JS/main thred), but the same browser-vendors really haven't come-up with an adequate replacement: the beeauty of alert/prompt/confirm is that their API is incredibly simple yet effective and also doesn't require the proggrammer to have any UI design-skills; I don't understand why browsers still don't offer a non-blocking Promie-based API for alert/prompt/confirm instead of them trying, in vain, to convince us that <dialog> is better in every situastion when it clearly isn't. ]
[+] [-] zamadatix|1 year ago|reply
I do agree <dialog> could have done with at least a little bit of TLC on the styling though, I just don't think it has to be 100% look and function like a system dialog outside the DOM to do it. Some base default styling to match the rest of the browser's default style would do wonders.
For PWAs (or any "web apps with more permissions than a random page should get just for being loaded") I could see where you wanted <dialogs> to go as a more well received idea though, similar to how there are separate things for styling the windows and interacting with the system for those more privileged pages.
[+] [-] ivanjermakov|1 year ago|reply
Another reason might be that vendor making it look like a native browser window would blur the line of death[1]. It would make it easier for malicious website to make a popup "browser update" in the middle of the page that redirects to seemingly legit Chrome download page and downloads modified executable.
[1]: https://textslashplain.com/2017/01/14/the-line-of-death/
[+] [-] zamalek|1 year ago|reply
You also have to be incredibly careful about how much visual control you allow over an actual dialog - especially making it look like the host OS. People get bamboozled by shitty in-browser fake virus alerts all the time, now add a real dialog, with real looks, that the user is forced to interact with, and you have a slam-dunk.
[+] [-] thousand_nights|1 year ago|reply
this is what completely holds back most built-in browser components from widespread usage, i suspect the vendors implementing it just don't care at all because it's not their problem
every company i've ever worked at had at least a somewhat consistently defined design language and it would look completely amateurish and out of place to use built in browser components in most places, regardless of how much html/css purists want that to be the case
unless that is fixed, it will never happen
[+] [-] simonw|1 year ago|reply
[+] [-] pygar|1 year ago|reply
[+] [-] pwg|1 year ago|reply
And, within three seconds of release, a <dialog> with this ability would be misused by advertisers to bring back the old pop-up windows that all browser's block by default now, because of advertiser misuse.
[+] [-] KTibow|1 year ago|reply
[+] [-] AlienRobot|1 year ago|reply
Nevertheless, I was also let down by it because it turns out if your <body> has a scrollbar, scroll wheel events bubble. There is a CSS property to stop them from bubbling but it doesn't work!
[+] [-] Sophira|1 year ago|reply
As a user, I would absolutely not want this. I appreciate being able to know which windows actually come from my browser and which are coming from a webpage.
[+] [-] pmarreck|1 year ago|reply
sadly this only reminds me of bad actors spoofing native dialog UI's to phish passwords and such
[+] [-] acoyfellow|1 year ago|reply
I use it everywhere. Optkit.com
[+] [-] cosmic_cheese|1 year ago|reply
I’ve long hoped for more APIs in the style of alert/prompt/confirm, which are more like ready-made building blocks rather than cement to make cinderblocks with as most web APIs tend to be. Anything that helps cut down on the amount of HTML, CSS, and JS required to be written or imported would be a substantial QoL improvement. This does not seem to be a popular view, unfortunately.
[+] [-] dehrmann|1 year ago|reply
I haven't done any serious web development for a decade, but did they ever get around to adding sane styling for drop-down menus?
[+] [-] mikae1|1 year ago|reply
And it can't be styled without JavaScript? That's how it works with <audio>. So utterly frustrating.
[+] [-] christophilus|1 year ago|reply
Yep. Welcome to the wonderful world of web standards.
[+] [-] stevage|1 year ago|reply
Eh, I beg to differ. Lots of use cases for that kind of dialog, for saving, confirming changes, etc etc.
[+] [-] lapcat|1 year ago|reply
[+] [-] apsurd|1 year ago|reply
All the wonderful value is in that they are standard. The web is great in its ubiquity. Love the web! Sure it's a mess, how could it not be?!
<dialog> is a win here in my view, especially for internal admin tools, I don't want to care about the latest flavor of frontend insanity. I just want to save screen space and open content as modal overlay on top of a main view.
[+] [-] AlienRobot|1 year ago|reply
SIGH...
To be honest, I think it's unlikely you will ever try to open the same dialog modally twice. If you need user input to open the dialog, and a modal dialog blocks user input, the only way for this to happen is if you have an input on the dialog that opens the dialog. If you are using asynchronous tasks to open the dialog, then you probably should keep track of what is open and what is not.
The same thing would happen if you were doing it on Qt, for example.
[+] [-] moffkalast|1 year ago|reply
[+] [-] benatkin|1 year ago|reply
Edit: I looked up standards positions and both support URLPattern.
[+] [-] pier25|1 year ago|reply
There's a <combobox> proposal in the works which is like a <select> on steroids [1].
Also the Popover API [1] already in browsers for toast alerts. And a popover hint proposal for tooltips[2].
[1] https://open-ui.org/components/combobox.explainer/
[2] https://mdn.github.io/dom-examples/popover-api/
[3] https://open-ui.org/components/popover-hint.research.explain...
[+] [-] somishere|1 year ago|reply
That said, my one major bugbear with it is the reliance on javascript. Yep, I expect all* users on my sites to arrive with JS enabled. But I also (selfishly?) derive some satisfaction from them not having to. Why can't I control the dialog's open state with CSS or a targeted button?
Would love to learn I'm wrong about this.
[+] [-] Heliodex|1 year ago|reply
Unsure about accessibility on this front, though it can't be worse than my previous attempts with hidden labels/checkboxes/form elements, while being much simpler and less hacky.
[+] [-] jazzypants|1 year ago|reply
https://css-tricks.com/invoker-commands-additional-ways-to-w...
[+] [-] pkphilip|1 year ago|reply
Each PAGE should be able to pull in common sections from the same page such as the header, sidebar, footer etc based on specific states selectable in each PAGE.
Yes, you can do the same thing with the current approaches by hiding and showing divs etc.. But if it were possible to support these approaches via specific tags in HTML it may help.
EXAMPLE:
[+] [-] 8n4vidtmkvmk|1 year ago|reply
[+] [-] andypants|1 year ago|reply
Normally a form will reload the page anyways so I guess this isn't a normal problem but I was using htmx.
[+] [-] replete|1 year ago|reply
Dialog works well for the most part, with a couple of CSS kludges here and there for the older browsers but otherwise straightforward to deal with. It's a decent addition to the web platform, but after 20 years of this I would like to stop making custom multi select controls every couple of years. Native controls good.
[0]: https://github.com/replete/biscuitman
[+] [-] Sateeshm|1 year ago|reply
[+] [-] Aachen|1 year ago|reply
MDN says this should work as intended out of the box
[+] [-] codethief|1 year ago|reply
[+] [-] itishappy|1 year ago|reply
Only the listeners added via JS seem to work correctly.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] silverwind|1 year ago|reply
[+] [-] poincaredisk|1 year ago|reply
This perplexes me. Why is it not recommended? Why put it in a standard and then recommend against it? What's wrong with it? The documentation is silent.
[+] [-] srathi|1 year ago|reply
[+] [-] Aachen|1 year ago|reply
Or a little userscript walking the DOM to find dialog elements and removes them. Or you could check if one can listen on them for show/open events, or hijack the show() method to do nothing
Lots of options I'd say
Not something I'd have in mind when using dialogs for legitimate purposes as a developer though. Don't wonder why you don't get my "do you really want to delete this item?" on my software when you block these altogether, but I guess you mean this for specific domains where it's used for ads (have yet to see dialog used for that, but no surprise that they'd exist)
[+] [-] quantadev|1 year ago|reply
[+] [-] joshdavham|1 year ago|reply
[+] [-] troupo|1 year ago|reply
And then boom! It was shipped everywhere with none of the issues discussed or fixed.
Why?
My tiny conspiracy theory is because browsers are hellbent on removing "legacy" APIs like confirm/prompt, and Chrome tried to remove it about half-a-year to a year before <dialog> was suddenly shipped everywhere: https://dev.to/richharris/stay-alert-d
[+] [-] chrishtr|1 year ago|reply
https://github.com/whatwg/html/wiki/dialog--initial-focus,-a...
https://github.com/whatwg/html/pull/8199
[+] [-] tanepiper|1 year ago|reply
https://tane.dev/2021/02/revisiting-dark-patterns-with-the-h...
[+] [-] skrebbel|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] palsecam|1 year ago|reply
Vignettes set their `z-index` CSS property to the max (2147483647), but a <dialog> is still higher on the z-plane (with no way to adjust that).
So if you click a link from a <dialog>, and an interstitial gets displayed, it’s under the <dialog>. It looks like nothing happened, that clicking is broken.
Fix in my case was to close() the <dialog> onclick.
[+] [-] unknown|1 year ago|reply
[deleted]