8 ms·

<dialog>: The Dialog Element

329 points by htunnicliff 2y ago

lapcat 2y ago
See my article "The HTML dialog element API is a mess": https://lapcatsoftware.com/articles/2024/2/1.html https://lapcatsoftware.com/articles/2024/2/1.html
- apsurd 2y ago
  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.
  - benatkin 2y ago
    It isn't wonderful though, it's mediocre :) They should err on the side of keeping the APIs small. Maybe it would be better if Web Components weren't a thing. I thought ARIA was handling dialogs well when it comes to accessibility. I like the idea of splitting JavaScript into JSSugar and JS0. (It will be nice if in the Deno lawsuit that the USPTO clarifies that Oracle owns the term JavaScript and JS is a free-for-all.)
  - troupo 2y ago
    > I don't think anyone would say web-standards are excellent, well designed and well-managed. and yet: > I don't want to care about the latest flavor of frontend insanity. Those not well managed, not well-designed and not-well managed standards somehow get a pass because that insanity is now a part of the browser? Do you know that Chrome argued that <dialog> should be removed from the platform because it's a bad API with multiple issues? https://github.com/whatwg/html/pull/4184#issuecomment-440405059 https://github.com/whatwg/html/pull/4184#issuecomment-440405...
    - magicalist 2y ago
      > Do you know that Chrome argued that <dialog> should be removed from the platform because it's a bad API with multiple issues? That's not at all what the comment you linked to says. It says there was an open question about if <dialog> should be removed from the spec because interest hadn't materialized from Firefox and Webkit for the element after four years (and wouldn't for another two years after that).
    - apsurd 2y ago
      What I'm saying is that the goal of standards and cross-platform support across time is valuable. The "open web" is a good thing for humanity. Work towards this goal is a huge shit show. And messy. But it's a good goal. The flavor-of-the-month frontend insanity is not serving this "good thing for humanity" goal as I call it. It's all well-intentioned and I'm not looking a gift horse in the mouth. But it is different.
- benatkin 2y ago
  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.
  - lapcat 2y ago
    > There's more where that came from. Google Chrome also did URLPattern, which I hope Chrome and Safari will hold firm on not supporting. Did you mean Firefox and Safari? Anyway, WebKit appears to be adding support for URLPattern.
    - benatkin 2y ago
      I did, and looked it up and Firefox chose the support position for it as well. I looked at the API again and I guess it's all right. It doesn't help much with tree-based routing like Roda (https://roda.jeremyevans.net/index.html https://roda.jeremyevans.net/index.html) but it seems useful for simple stuff.
- AlienRobot 2y ago
  >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.
  - lapcat 2y ago
    > To be honest, I think it's unlikely you will ever try to open the same dialog modally twice. This is a strange reaction to the blog post, because as you read, it's a certainty that my code did try to open the same dialog modally twice. This was a bug, of course, which would have been revealed in development if not for the change in the standard.
- moffkalast 2y ago
  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.
ulrischa 2y ago
Why is this on the front page? It is nothing special
- rock_artist 2y ago
  I guess because the complete standardization is new. The page says: > This page was last modified on Oct 29, 2024
  - cantSpellSober 2y ago
    Which seems to simply add <dialog> to the docs for the `cancel` event https://github.com/mdn/content/commit/d2421d25d1676cc11b01cc4981061e4d0aa78e95 https://github.com/mdn/content/commit/d2421d25d1676cc11b01cc... https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/cancel_event https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogE... (<dialog> has been around for a decade)
    - ulrischa 2y ago
      That's what I mean
- Mystery-Machine 2y ago
  No idea. If it was the new `popover` attribute, I'd understand. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/popover https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
- palsecam 2y ago
  It doesn’t have to be brand new to be on the front page. Good ol’ or reference content is suitable too. For instance, see this recent thread https://news.ycombinator.com/item?id=41967897 https://news.ycombinator.com/item?id=41967897 about the “418 I’m a teapot” HTTP status code, also linking to MDN. It was nothing new neither.
- deleted 2y ago
  [deleted]
DaiPlusPlus 2y ago
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. ]
- mikae1 2y ago
  > But my biggest let-down with the <dialog> element is that it's comnpletely unstyled And it can't be styled without JavaScript? That's how it works with <audio>. So utterly frustrating.
  - fzzzy 2y ago
    It can be styled with css. Edit: Example: https://gist.github.com/fzzzy/f5f1af66ee8fff478ffb3698ac9f80d5 https://gist.github.com/fzzzy/f5f1af66ee8fff478ffb3698ac9f80...
Sateeshm 2y ago
Normal close in most examples not working for me. Android Firefox
- itishappy 2y ago
  Same here. Chrome, Windows 10. Only the listeners added via JS seem to work correctly.
- codethief 2y ago
  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.
  - extra88 2y ago
    As the MDN article documents, you don't necessarily have to use JavaScript: ```HTML <form method="dialog"> <button>Close</button> </form> ```
- Aachen 2y ago
  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
palsecam 2y ago
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.
- zachrip 2y ago
  This is a feature
  - palsecam 2y ago
    Yes, but that can be surprising. That you cannot adjust the z-index is disturbing, especially given that you have to style <dialog> yourself if you wanna make it look any good (as others have reported here). Also, for the record, alert() is still higher than <dialog> on the plane (see https://i.imgur.com/tzKOEF2.png https://i.imgur.com/tzKOEF2.png).
    - Sesse__ 2y ago
      FWIW, it's on a separate layer that's not affected by z-index: https://developer.mozilla.org/en-US/docs/Glossary/Top_layer https://developer.mozilla.org/en-US/docs/Glossary/Top_layer
- silverwind 2y ago
  Use `.show()` instead of `.showModal()` and create your own backdrop.
andypants 2y ago
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.
- apsurd 2y ago
  Your last sentence is likely right, by default the form issues a network request. I've been using a dialog form to update an iframe (it's an editor) so it does work as normal the target iframe gets reloaded. It does not close the dialog though. I can't produce the case where hitting enter closes the dialog. It should be the same as `<button type='submit'>submit</button>` which also does not close the dialog. FWIW I learned yesterday that a button _can_ close the dialog: <button formmethod="dialog">Update & Close</button>
- Andrex 2y ago
  > 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. preventDefault and stopPropagation?
  - andypants 2y ago
    There's no event for the dialog about to close, only an event for after the dialog closes. You can prevent default on the enter key and space key, but that obviously breaks the form ux. There is an event for the dialog about to close from pressing the escape key. No idea why it's only for closing via escape key.
    - extra88 2y ago
      I think they meant prevent the form submission on the `submit` event and use JavaScript to make the submission. https://developer.mozilla.org/en-US/docs/Learn/Forms/Sending_forms_through_JavaScript https://developer.mozilla.org/en-US/docs/Learn/Forms/Sending...
srathi 2y ago
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?
- Aachen 2y ago
  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)
troupo 2y ago
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-440405059 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 https://dev.to/richharris/stay-alert-d
- chrishtr 2y ago
  The issues were fixed actually. https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal https://github.com/whatwg/html/wiki/dialog--initial-focus,-a... https://github.com/whatwg/html/pull/8199 https://github.com/whatwg/html/pull/8199
  - troupo 2y ago
    Fixed after dialog was rapidly pushed into production across all browsers. - Argued that dialog should be removed: 2018 - Tried to force-remove confirm/prompt: mid-2021 - Dialog rushed into all browsers: March 8-14, 2022. - The linked proposal for a fix: March 04, 2022 - Request for position on standard: Jan 18, 2023 - The proposal merged into the standard: Jan 26, 2023 - Implemented in browsers: ?? (Webkit is possibly July 2024: https://bugs.webkit.org/show_bug.cgi?id=250795 https://bugs.webkit.org/show_bug.cgi?id=250795) "Actually" Dialog was literally rushed into all browsers without bothering to fix the issues that plagued it for a decade. Some of them were fixed post-factum because now you couldn't ignore these issues.
joshdavham 2y ago
I still remember being confused about the differences between dialogs, popovers, and modal vs non-modal elements when I was first learning web development.
quantadev 2y ago
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!
- akira2501 2y ago
  So a few years ago I went into my chrome configuration and added a new custom "Site Search". It's shortcut is "mdn" and the URL is "https://developer.mozilla.org/en-US/search?q=%s&w=3&qs=plugin https://developer.mozilla.org/en-US/search?q=%s&w=3&qs=plugi..." Now you can just "mdn <something>" in your omnibar and it will take you straight to the subject page or to a search results page. I find this shortcut invaluable when developing for the web.
  - quantadev 2y ago
    very helpful link, thanks! I don't know what ominibar is (maybe Mac stuff), but I'm on Linux, but I replaced the "q=%s" with my string and it works. nice!
    - akira2501 2y ago
      https://zapier.com/blog/add-search-engine-to-chrome/ https://zapier.com/blog/add-search-engine-to-chrome/
      - quantadev 2y ago
        cool, thanks.
    - skrebbel 2y ago
      "omnibar" is just chrome's slightly pretentious name for the address bar.
- 2y ago
deleted 2y ago
[deleted]
replete 2y ago
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. [0]: https://github.com/replete/biscuitman https://github.com/replete/biscuitman
- deleted 2y ago
  [deleted]
- replete 2y ago
  Surprised by the downvotes to be honest, it's relevant. It's okay, I hate cookie popups also.
  - skrebbel 2y ago
    fwiw i'm surprised by the downvotes too (and upvoted it to compensate). that said, complaining about downvotes is usually frowned upon here.
deleted 2y ago
[deleted]
silverwind 2y ago
The worst thing about `<dialog>` is that modal ones are placed in the CSS "top layer" which obstructs portalled content like tooltips and dropdowns.
- plonq 2y ago
  Once we can use popover and anchor positioning, tooltips and drop downs can also be in the top layer. I can’t wait
  - 8n4vidtmkvmk 2y ago
    This was never an issue for me in React. The top layer seems unnecessary. Just put your portal or fancy code such that it puts all those popovers at the end. If you order your DOM correctly, you almost never have to touch the z-index.
    - plonq 2y ago
      The point is it will be possible without a framework
      - 8n4vidtmkvmk 2y ago
        `document.body.appendChild(newElement);` is pretty easy too.
pier25 2y ago
Regardless of the implementation I think this was a step in the right direction. 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/ https://open-ui.org/components/combobox.explainer/ [2] https://mdn.github.io/dom-examples/popover-api/ https://mdn.github.io/dom-examples/popover-api/ [3] https://open-ui.org/components/popover-hint.research.explainer/ https://open-ui.org/components/popover-hint.research.explain...
somishere 2y ago
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? Would love to learn I'm wrong about this.
- Heliodex 2y ago
  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.
  - somishere 2y ago
    Re. accessibility, the main feature is that dialogs can be "modal" - meaning the rest of the page is non-interactive while the dialog is open - ensuring a focus trap. Popovers are always non-modal, which can be problematic depending on the use-case. Of course it's possible to manually implement a focus trap, but it's complex and it's javascript.
    - extra88 2y ago
      Yes, I wish when the popover attributes were created there was something included for opening a modal dialog. I think it is possible to use popover to open a dialog non-modally and use progressive enhancement to replace that behavior with `.showModal()`.
- jazzypants 2y ago
  This is coming with invokers. https://css-tricks.com/invoker-commands-additional-ways-to-work-with-dialog-popover-and-more/ https://css-tricks.com/invoker-commands-additional-ways-to-w...
deleted 2y ago
[deleted]
pkphilip 2y ago
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. EXAMPLE: <COMMON> <script> .. common javascript elements here </script> <SECTION id="header"> ... </SECTION> <SECTION id="sidebar"> ... </SECTION> <SECTION id="footer"> ... </SECTION> </COMMON> <PAGE default name="Home"> <INCLUDE from="header"/> <INCLUDE from="sidebar"/> <DIV> ..... </DIV> <INCLUDE from="footer"/> </PAGE> <PAGE name="Login"> <INCLUDE from="header"/> <DIV> ..... </DIV> <INCLUDE from="footer"/> </PAGE> <PAGE name="Profile"> <INCLUDE from="header"/> <INCLUDE from="sidebar"/> <DIV> ..... </DIV> <INCLUDE from="footer"/> </PAGE>
- 8n4vidtmkvmk 2y ago
  I think there have been some improvements to print stylesheets recently that let you do just that for printing, but not for the screen AFAIK.
divbzero 2y ago
Other delightfully interactive HTML elements include… File pickers: <input type="file"> Color pickers: <input type="color"> Date/time pickers: <input type="month"> <input type="date"> <input type="time"> <input type="datetime-local"> Numeric sliders: <input type="range" min="0" max="5"> Suggested options for text fields: <input list="fonts"> <datalist id="fonts"> <option value="Courier New"></option> <option value="Garamond"></option> <option value="Georgia"></option> <option value="Tahoma"></option> <option value="Times New Roman"></option> </datalist> Summaries with expandable details: <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> Media players with controls: <audio controls src="example.mp3"></audio> <video controls src="example.mp4"></video>
- vintermann 2y ago
  All of which these days are going to be unused in favor of some toolkit, because they don't behave predictably enough across browsers / browser versions.
  - esrauch 2y ago
    Except file, no one is giving the browser full access to their files so that it can render a shitty file picker
    - pests 2y ago
      The browser already has full access to their files.
      - lobsterthief 2y ago
        But websites don’t
tanepiper 2y ago
The dialog tag is not a good idea - it can still be used to completely force a user into clicking and forcing an action they can't control https://tane.dev/2021/02/revisiting-dark-patterns-with-the-html-dialog-tag/ https://tane.dev/2021/02/revisiting-dark-patterns-with-the-h...
- skrebbel 2y ago
  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?
poincaredisk 2y ago
>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.

329 points by htunnicliff 2y ago

See my article "The HTML dialog element API is a mess": https://lapcatsoftware.com/articles/2024/2/1.html https://lapcatsoftware.com/articles/2024/2/1.html

apsurd 2y ago
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.
- benatkin 2y ago
  It isn't wonderful though, it's mediocre :) They should err on the side of keeping the APIs small. Maybe it would be better if Web Components weren't a thing. I thought ARIA was handling dialogs well when it comes to accessibility. I like the idea of splitting JavaScript into JSSugar and JS0. (It will be nice if in the Deno lawsuit that the USPTO clarifies that Oracle owns the term JavaScript and JS is a free-for-all.)
- troupo 2y ago
  > I don't think anyone would say web-standards are excellent, well designed and well-managed. and yet: > I don't want to care about the latest flavor of frontend insanity. Those not well managed, not well-designed and not-well managed standards somehow get a pass because that insanity is now a part of the browser? Do you know that Chrome argued that <dialog> should be removed from the platform because it's a bad API with multiple issues? https://github.com/whatwg/html/pull/4184#issuecomment-440405059 https://github.com/whatwg/html/pull/4184#issuecomment-440405...
  - magicalist 2y ago
    > Do you know that Chrome argued that <dialog> should be removed from the platform because it's a bad API with multiple issues? That's not at all what the comment you linked to says. It says there was an open question about if <dialog> should be removed from the spec because interest hadn't materialized from Firefox and Webkit for the element after four years (and wouldn't for another two years after that).
  - apsurd 2y ago
    What I'm saying is that the goal of standards and cross-platform support across time is valuable. The "open web" is a good thing for humanity. Work towards this goal is a huge shit show. And messy. But it's a good goal. The flavor-of-the-month frontend insanity is not serving this "good thing for humanity" goal as I call it. It's all well-intentioned and I'm not looking a gift horse in the mouth. But it is different.
benatkin 2y ago
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.
- lapcat 2y ago
  > There's more where that came from. Google Chrome also did URLPattern, which I hope Chrome and Safari will hold firm on not supporting. Did you mean Firefox and Safari? Anyway, WebKit appears to be adding support for URLPattern.
  - benatkin 2y ago
    I did, and looked it up and Firefox chose the support position for it as well. I looked at the API again and I guess it's all right. It doesn't help much with tree-based routing like Roda (https://roda.jeremyevans.net/index.html https://roda.jeremyevans.net/index.html) but it seems useful for simple stuff.
AlienRobot 2y ago
>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.
- lapcat 2y ago
  > To be honest, I think it's unlikely you will ever try to open the same dialog modally twice. This is a strange reaction to the blog post, because as you read, it's a certainty that my code did try to open the same dialog modally twice. This was a bug, of course, which would have been revealed in development if not for the change in the standard.
moffkalast 2y ago
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.

ulrischa 2y ago

Why is this on the front page? It is nothing special

rock_artist 2y ago
I guess because the complete standardization is new. The page says: > This page was last modified on Oct 29, 2024
- cantSpellSober 2y ago
  Which seems to simply add <dialog> to the docs for the `cancel` event https://github.com/mdn/content/commit/d2421d25d1676cc11b01cc4981061e4d0aa78e95 https://github.com/mdn/content/commit/d2421d25d1676cc11b01cc... https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/cancel_event https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogE... (<dialog> has been around for a decade)
  - ulrischa 2y ago
    That's what I mean
Mystery-Machine 2y ago
No idea. If it was the new `popover` attribute, I'd understand. https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/popover https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
palsecam 2y ago
It doesn’t have to be brand new to be on the front page. Good ol’ or reference content is suitable too. For instance, see this recent thread https://news.ycombinator.com/item?id=41967897 https://news.ycombinator.com/item?id=41967897 about the “418 I’m a teapot” HTTP status code, also linking to MDN. It was nothing new neither.
deleted 2y ago
[deleted]

DaiPlusPlus 2y ago

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

mikae1 2y ago
> But my biggest let-down with the <dialog> element is that it's comnpletely unstyled And it can't be styled without JavaScript? That's how it works with <audio>. So utterly frustrating.
- fzzzy 2y ago
  It can be styled with css. Edit: Example: https://gist.github.com/fzzzy/f5f1af66ee8fff478ffb3698ac9f80d5 https://gist.github.com/fzzzy/f5f1af66ee8fff478ffb3698ac9f80...

Sateeshm 2y ago

Normal close in most examples not working for me. Android Firefox

itishappy 2y ago
Same here. Chrome, Windows 10. Only the listeners added via JS seem to work correctly.
codethief 2y ago
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.
- extra88 2y ago
  As the MDN article documents, you don't necessarily have to use JavaScript: ```HTML <form method="dialog"> <button>Close</button> </form> ```
Aachen 2y ago
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

palsecam 2y ago

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.

zachrip 2y ago
This is a feature
- palsecam 2y ago
  Yes, but that can be surprising. That you cannot adjust the z-index is disturbing, especially given that you have to style <dialog> yourself if you wanna make it look any good (as others have reported here). Also, for the record, alert() is still higher than <dialog> on the plane (see https://i.imgur.com/tzKOEF2.png https://i.imgur.com/tzKOEF2.png).
  - Sesse__ 2y ago
    FWIW, it's on a separate layer that's not affected by z-index: https://developer.mozilla.org/en-US/docs/Glossary/Top_layer https://developer.mozilla.org/en-US/docs/Glossary/Top_layer
silverwind 2y ago
Use `.show()` instead of `.showModal()` and create your own backdrop.

andypants 2y ago

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.

apsurd 2y ago
Your last sentence is likely right, by default the form issues a network request. I've been using a dialog form to update an iframe (it's an editor) so it does work as normal the target iframe gets reloaded. It does not close the dialog though. I can't produce the case where hitting enter closes the dialog. It should be the same as `<button type='submit'>submit</button>` which also does not close the dialog. FWIW I learned yesterday that a button _can_ close the dialog: <button formmethod="dialog">Update & Close</button>
Andrex 2y ago
> 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. preventDefault and stopPropagation?
- andypants 2y ago
  There's no event for the dialog about to close, only an event for after the dialog closes. You can prevent default on the enter key and space key, but that obviously breaks the form ux. There is an event for the dialog about to close from pressing the escape key. No idea why it's only for closing via escape key.
  - extra88 2y ago
    I think they meant prevent the form submission on the `submit` event and use JavaScript to make the submission. https://developer.mozilla.org/en-US/docs/Learn/Forms/Sending_forms_through_JavaScript https://developer.mozilla.org/en-US/docs/Learn/Forms/Sending...

srathi 2y ago

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?

Aachen 2y ago
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)

troupo 2y ago

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-440405059 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 https://dev.to/richharris/stay-alert-d

chrishtr 2y ago
The issues were fixed actually. https://github.com/whatwg/html/wiki/dialog--initial-focus,-a-proposal https://github.com/whatwg/html/wiki/dialog--initial-focus,-a... https://github.com/whatwg/html/pull/8199 https://github.com/whatwg/html/pull/8199
- troupo 2y ago
  Fixed after dialog was rapidly pushed into production across all browsers. - Argued that dialog should be removed: 2018 - Tried to force-remove confirm/prompt: mid-2021 - Dialog rushed into all browsers: March 8-14, 2022. - The linked proposal for a fix: March 04, 2022 - Request for position on standard: Jan 18, 2023 - The proposal merged into the standard: Jan 26, 2023 - Implemented in browsers: ?? (Webkit is possibly July 2024: https://bugs.webkit.org/show_bug.cgi?id=250795 https://bugs.webkit.org/show_bug.cgi?id=250795) "Actually" Dialog was literally rushed into all browsers without bothering to fix the issues that plagued it for a decade. Some of them were fixed post-factum because now you couldn't ignore these issues.

joshdavham 2y ago

I still remember being confused about the differences between dialogs, popovers, and modal vs non-modal elements when I was first learning web development.

quantadev 2y ago

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!

akira2501 2y ago
So a few years ago I went into my chrome configuration and added a new custom "Site Search". It's shortcut is "mdn" and the URL is "https://developer.mozilla.org/en-US/search?q=%s&w=3&qs=plugin https://developer.mozilla.org/en-US/search?q=%s&w=3&qs=plugi..." Now you can just "mdn <something>" in your omnibar and it will take you straight to the subject page or to a search results page. I find this shortcut invaluable when developing for the web.
- quantadev 2y ago
  very helpful link, thanks! I don't know what ominibar is (maybe Mac stuff), but I'm on Linux, but I replaced the "q=%s" with my string and it works. nice!
  - akira2501 2y ago
    https://zapier.com/blog/add-search-engine-to-chrome/ https://zapier.com/blog/add-search-engine-to-chrome/
    - quantadev 2y ago
      cool, thanks.
  - skrebbel 2y ago
    "omnibar" is just chrome's slightly pretentious name for the address bar.
2y ago

deleted 2y ago

[deleted]

replete 2y ago

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. [0]: https://github.com/replete/biscuitman https://github.com/replete/biscuitman

deleted 2y ago
[deleted]
replete 2y ago
Surprised by the downvotes to be honest, it's relevant. It's okay, I hate cookie popups also.
- skrebbel 2y ago
  fwiw i'm surprised by the downvotes too (and upvoted it to compensate). that said, complaining about downvotes is usually frowned upon here.

deleted 2y ago

[deleted]

silverwind 2y ago

The worst thing about `<dialog>` is that modal ones are placed in the CSS "top layer" which obstructs portalled content like tooltips and dropdowns.

plonq 2y ago
Once we can use popover and anchor positioning, tooltips and drop downs can also be in the top layer. I can’t wait
- 8n4vidtmkvmk 2y ago
  This was never an issue for me in React. The top layer seems unnecessary. Just put your portal or fancy code such that it puts all those popovers at the end. If you order your DOM correctly, you almost never have to touch the z-index.
  - plonq 2y ago
    The point is it will be possible without a framework
    - 8n4vidtmkvmk 2y ago
      `document.body.appendChild(newElement);` is pretty easy too.

pier25 2y ago

Regardless of the implementation I think this was a step in the right direction. 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/ https://open-ui.org/components/combobox.explainer/ [2] https://mdn.github.io/dom-examples/popover-api/ https://mdn.github.io/dom-examples/popover-api/ [3] https://open-ui.org/components/popover-hint.research.explainer/ https://open-ui.org/components/popover-hint.research.explain...

somishere 2y ago

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? Would love to learn I'm wrong about this.

Heliodex 2y ago
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.
- somishere 2y ago
  Re. accessibility, the main feature is that dialogs can be "modal" - meaning the rest of the page is non-interactive while the dialog is open - ensuring a focus trap. Popovers are always non-modal, which can be problematic depending on the use-case. Of course it's possible to manually implement a focus trap, but it's complex and it's javascript.
  - extra88 2y ago
    Yes, I wish when the popover attributes were created there was something included for opening a modal dialog. I think it is possible to use popover to open a dialog non-modally and use progressive enhancement to replace that behavior with `.showModal()`.
jazzypants 2y ago
This is coming with invokers. https://css-tricks.com/invoker-commands-additional-ways-to-work-with-dialog-popover-and-more/ https://css-tricks.com/invoker-commands-additional-ways-to-w...

deleted 2y ago

[deleted]

pkphilip 2y ago

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. EXAMPLE: <COMMON> <script> .. common javascript elements here </script> <SECTION id="header"> ... </SECTION> <SECTION id="sidebar"> ... </SECTION> <SECTION id="footer"> ... </SECTION> </COMMON> <PAGE default name="Home"> <INCLUDE from="header"/> <INCLUDE from="sidebar"/> <DIV> ..... </DIV> <INCLUDE from="footer"/> </PAGE> <PAGE name="Login"> <INCLUDE from="header"/> <DIV> ..... </DIV> <INCLUDE from="footer"/> </PAGE> <PAGE name="Profile"> <INCLUDE from="header"/> <INCLUDE from="sidebar"/> <DIV> ..... </DIV> <INCLUDE from="footer"/> </PAGE>

8n4vidtmkvmk 2y ago
I think there have been some improvements to print stylesheets recently that let you do just that for printing, but not for the screen AFAIK.

divbzero 2y ago

Other delightfully interactive HTML elements include… File pickers: <input type="file"> Color pickers: <input type="color"> Date/time pickers: <input type="month"> <input type="date"> <input type="time"> <input type="datetime-local"> Numeric sliders: <input type="range" min="0" max="5"> Suggested options for text fields: <input list="fonts"> <datalist id="fonts"> <option value="Courier New"></option> <option value="Garamond"></option> <option value="Georgia"></option> <option value="Tahoma"></option> <option value="Times New Roman"></option> </datalist> Summaries with expandable details: <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> Media players with controls: <audio controls src="example.mp3"></audio> <video controls src="example.mp4"></video>

vintermann 2y ago
All of which these days are going to be unused in favor of some toolkit, because they don't behave predictably enough across browsers / browser versions.
- esrauch 2y ago
  Except file, no one is giving the browser full access to their files so that it can render a shitty file picker
  - pests 2y ago
    The browser already has full access to their files.
    - lobsterthief 2y ago
      But websites don’t

tanepiper 2y ago

The dialog tag is not a good idea - it can still be used to completely force a user into clicking and forcing an action they can't control https://tane.dev/2021/02/revisiting-dark-patterns-with-the-html-dialog-tag/ https://tane.dev/2021/02/revisiting-dark-patterns-with-the-h...

skrebbel 2y ago
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?

poincaredisk 2y ago

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