from Hacker News

<dialog>: The Dialog Element

by htunnicliff on 12/6/24, 7:09 PM with 153 comments

by divbzero on 12/7/24, 6:41 AM

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>&lt;details&gt;</code> elements share the same name.
  </details>

Media players with controls:

  <audio controls src="example.mp3"></audio>
  <video controls src="example.mp4"></video>

by DaiPlusPlus on 12/6/24, 7:39 PM
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. ]
by lapcat on 12/6/24, 7:31 PM
See my article "The HTML dialog element API is a mess": https://lapcatsoftware.com/articles/2024/2/1.html
by pier25 on 12/7/24, 12:42 AM
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/
[2] https://mdn.github.io/dom-examples/popover-api/
[3] https://open-ui.org/components/popover-hint.research.explain...
by somishere on 12/7/24, 3:15 AM
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.

by pkphilip on 12/7/24, 4:39 AM

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>

by andypants on 12/6/24, 8:25 PM
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.
by replete on 12/6/24, 11:15 PM
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
by Sateeshm on 12/6/24, 7:40 PM
Normal close in most examples not working for me. Android Firefox
by silverwind on 12/7/24, 12:18 AM
The worst thing about `<dialog>` is that modal ones are placed in the CSS "top layer" which obstructs portalled content like tooltips and dropdowns.
by poincaredisk on 12/7/24, 6:19 PM
>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.
by srathi on 12/6/24, 8:29 PM
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?
by quantadev on 12/6/24, 11:05 PM
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!
by joshdavham on 12/6/24, 9:40 PM
I still remember being confused about the differences between dialogs, popovers, and modal vs non-modal elements when I was first learning web development.
by troupo on 12/6/24, 9:33 PM
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
by tanepiper on 12/7/24, 10:34 AM
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-h...
by palsecam on 12/6/24, 8:21 PM
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.
by ulrischa on 12/6/24, 7:31 PM
Why is this on the front page? It is nothing special