Silkenweb Example: Hackernews Clone

<dialog>: The Dialog Element

329 points by htunnicliff 7 months ago | 153 comments

divbzero 7 months 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>&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>
```
- vintermann 7 months 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.
  - nikodotio 7 months ago
    I use all of them pretty consistently! I try not to have them do magic, but using native date pickers and dropdowns and selects saves so much time and headache - and they work consistently.
    - porridgeraisin 7 months ago
      How do you use audio/video consistently across browsers? It looks quite different across the browser/platform combination matrix.
  - eek2121 7 months ago
    I use them! I just add CSS to pretty them up.
    - eek2121 7 months ago
      (not everyone is into using some hot new framework, some of use stick with HTML/CSS/JavaScript)
  - esrauch 7 months ago
    Except file, no one is giving the browser full access to their files so that it can render a shitty file picker
    - pests 7 months ago
      The browser already has full access to their files.
  - dv_dt 7 months ago
    Depends if you mean consistent to the os or browser or consistent to the js framework - I would suggest that most casual users don't notice and actually do better if its consistent to the os or browser they use
    Well some other comment mentioned audio/video and those are seemingly aways different
    - wongarsu 7 months ago
      > Well some other comment mentioned audio/video and those are seemingly aways different
      Which is probably fine for your users. In every browser it plays video and has basic controls like a start/pause button, a timeline and a volume control. While the video is playing they even look identical: it's the video, playing; with controls only visible on hover.
      The differences aren't an issue for the actual user, they are an issue for the designer that tries to have the website look and feel the same everywhere. Preferably look the same as it does on their MacBook.
- mikae1 7 months ago
  > Media players with controls:
  > <audio controls src="example.mp3"></audio>
  > <video controls src="example.mp4"></video>
  Which look different in every single browser and can't be styled without JavaScript. Wish these were implemented better.
  - BeFlatXIII 7 months ago
    I wish more websites left things with default styling.
  - wwweston 6 months ago
    As long as the essential controls are there (play/pause, volume, transport) and don't have serious UX sins (tiny or otherwise lacking touch targets) restyling them is overrated.
    And an unfortunate number of recreated controls seem to have the serious UX sins.
    "looks different in every single browser" is a minor issue. Might be nice if they were restylable via CSS, though.
- gonzo41 7 months ago
  d<atalist> is a gem. Love it.
DaiPlusPlus 7 months 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. ]
- zamadatix 7 months ago
  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.
- ivanjermakov 7 months ago
  > is that it's comnpletely unstyled
  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 7 months ago
  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.
  - tredre3 7 months ago
    > 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).
    Good news then, because alert/prompt/confirm do not block the window in any modern browser!
    In Firefox it only blocks the viewport of the current tab, so it behaves exactly like a DIY modal. In Chromium browsers it does pop over part of the browser UI, but it still doesn't block the window; You interact with the tab bar, address bar, menu, etc.
    - DaiPlusPlus 7 months ago
      > because alert/prompt/confirm do not block the window in any modern browser!
      Correct: they don't block the browser's desktop UI thread - but they do block the web-page's thread - and for abvout the past decade we can't move alert/prompt/confirm prompts: Chrome forces them to appear at the very top, dead-centre, and you can't scroll the page while it's open.
  - berkes 7 months ago
    As can be seen when attaching an image. When you have to look up something in another tab. I now have to first close the file picking modal, before I can use anything in the browser.
    It might be Gnome/Firefox only, IDK. But this modal thing is very bad UX.
    The alternative is also bad, TBH: where the file picker is now gone somewhere in the sea of open windows. Maybe the middle-ground, where the file-picker is "attached" to the one tab that opened it, and goes away once other tabs and window chrome is engaged, but I guess thats hard to do in a WM?
  - quantadev 7 months ago
    If you don't think "Modals" are needed that just means you've never needed one yourself.
    There are lots of cases where they're almost mandatory. I have an app where some interactions will end up with 4 to 5 layers of stacked modals. Like you edit a node, then you open the sharing dialog to share it, then you need pick a person to share to, then you need to add a new person, then you need to select who to add, etc. Most websites are trivial and thus don't need dialogs at all but there are some which are full featured apps (like mine) where Modals are a critical thing to have.
    - Digit-Al 7 months ago
      I spent years designing interfaces for Windows Forms applications. There is no neccessity for sharing to be a dialog - it should be a wizard; and could even open in a new tab in a web application. Then the user can cancel either by pressing the cancel button (which would close the tab) or by just closing the tab. Selecting who to add, or adding a new person then just become pages in the wizard.
    - epcoa 7 months ago
      No idea why you think any of that should block the entire browser including all other tabs, but that sounds like awful design.
      Furthermore, editing a node, a sharing interaction and adding a person all sound like they could be handled by modeless dialogs or independent editors. Frankly, modals are typically a hallmark of lazy design.
- thousand_nights 7 months ago
  > comnpletely unstyled,
  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
  - MrJohz 7 months ago
    I think you might be talking about a different thing to the other poster.
    The dialog element behaves exactly how you'd want it to behave for a company with their own design language — you can style every part of it exactly how you need it (including the backdrop, the positioning and size of the dialog element itself, borders, colours, contents, etc). Depending on how you implement the design language, you can either apply those styles to the dialog element in general, or provide a custom component that wraps the dialog element and provides the styles you need.
    What the previous poster was complaining about was the opposite situation: they aren't working with their own design language, and instead want to use native-looking HTML elements (the default inputs, selects, buttons, etc). However, the dialog element does not provide a native look-and-feel, and instead is very minimalistic, providing only the base that developers can add their own styles to.
    That said, I think the browser implementors have made the correct choice here. The dialog element is not a native popup, and doesn't behave like a native popup at all, so it doesn't make sense to style it natively. In addition, the more styles they provide as part of the user-agent styling, the harder it is to reset those styles if you want to do something different. Apart from inputs, browsers fairly consistently stick with providing the minimum possible styling for an element to be usable, and this means that developers have the largest range of freedom to use those elements as they like.
  - ryandrake 7 months ago
    I feel like every company's (different/contrasting) "design language" and their insistence on using it, ends up being yet another weird looking thing on my computer. I'd rather decide for myself the fonts, color scheme, look and feel, etc. for applications on my computer, and have applications be consistent and respect those preferences. Rather than have some artist I don't know 2,000 miles away from me simply decide what a dialog should look like (and it's always totally different than what some other artist decided a dialog should look like).
    - xp84 7 months ago
      I think most of us here who aren't self-important "UX designers" (or branding consultants) would agree with you, but the decision makers responsible for most of the sites on the Web disagree/don't care what we'd like. They want their site to look identical on all platforms and browsers, and to have their "signature" design language, to heck with what users might expect. It's why you see stupid things like pixel-perfect clones of the iOS "switch" control brought to the Web.
      So, anyway, if the `<dialog>` is ever to have a chance at adoption, instead of the "div soup and 1000 lines of JS and CSS modal" we've had everywhere since 2008 or so, it really should be blank slate for the "UX Designer" who fancies themself a real artist can vomit their personal brand of "elegant but bold, minimalist, flat design" onto the DOM.
      If it's not completely skinnable, they'll just keep insisting on building div soup modals forever.
    - DaiPlusPlus 7 months ago
      "But we don't want to look like everyone else"
  - chrishtr 7 months ago
    The <dialog> element is fully styleable, including its backdrop (the MDN article explains how for the latter). In Chrome you can also fully style animations opening and closing a <dialog> or popover.
    https://developer.chrome.com/blog/entry-exit-animations
    - salzig 7 months ago
      @starting-style support is quite good in all browsers, not just chrome. https://caniuse.com/?search=%20%40starting-style
  - dylan604 7 months ago
    the most commonly used element that I use is the date picker. i hate using it, but i'm not loading some library or framework just for it either.
    - 8n4vidtmkvmk 7 months ago
      The native datepicker is weird, at least in Chrome. I was playing around with it, and if you give it milliseconds it will render a millisecond picker in intervals of 100. If you give it a nice round minute, then ms and s disappear from the UI. There's no attribute to control this.
      I also want a non-local time picker. Let me specify a time that the server can properly interpret as a moment in time. i.e specify an offset somehow.
    - thousand_nights 7 months ago
      i don't know what context you're using it in, but imagine a company like airbnb or booking.com using the built in date picker on their front page
      you might as well cut their public valuation in half at that point. it's just not worth it to use the completely neglected and anemic components that are part of the browser, they are a joke
- simonw 7 months ago
  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?");
```
  Demo here: https://tools.simonwillison.net/prompts-js - code written by o1: https://chatgpt.com/share/67539c28-4df0-8006-b021-4f468e011f...
  - jtwaleson 7 months ago
    For a company that had a giant 30 minute wizard in the web interface, I wrote a wizard engine in VueJS that works similarly. It's served hundreds of thousands of users since 2019 and went through medical device certification :) Took me quite some time to realize we can use `await` to wait for user input too, not just APIs etc.
    I recently re-created parts of it from memory for a hobby project and just now open-sourced it: https://github.com/jtwaleson/wizard-engine
    The neat thing is that we can program the complex logic of the wizard with the full power of the programming language. By making each screen in the wizard a function that has input parameters and a return value, we can treat it like any other function. Show the same screen 3x in a row? Use a for loop. Show a screen with input that depends on the output of the previous step? Just use a variable to store the results.
    - zelphirkalt 7 months ago
      Why is it any surprise that one can use await to wait for user input? It is just promises under the hood, right? So that is exactly like one would expect a promise using dialog to work.
  - simonw 7 months ago
    I improved this (by porting it to the dialog.showModal() API, relevant to this post) and shipped it to NPM as a package called prompts-js.
    Code here: https://github.com/simonw/prompts-js
    Blog writeup: https://simonwillison.net/2024/Dec/7/prompts-js/
  - DaiPlusPlus 7 months ago
    Seeing ChatGPT use `return new Promise(...` directly inside an `async function` makes me somewhat less apprehensive about the future.
  - svieira 7 months ago
    While they are nice, they don't block the event loop. That's definitely a feature you would need if you're aiming to replace `alert` and friends. As an alternative, yeah, that's a pretty reasonable API.
- pygar 7 months ago
  There are some efforts being made on the styling front by a W3C Community Group: https://open-ui.org/
- pwg 7 months ago
  > 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.
- KTibow 7 months ago
  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.
- AlienRobot 7 months ago
  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!
- Sophira 7 months ago
  > 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.
  - Sophira 6 months ago
    I was looking at this current again just now, and realised it could use a bit of explanation.
    I typically have lots of tabs open at once. Hundreds, in some cases. A window escaping the bounds of the viewport would imply that it also escapes the bounds of the browser tab - which is to say, can pop up no matter which tab I'm on at any given moment.
    The better solution, I believe, would be to pop up any notification using the notification API, and then once the user has been taken to the browser tab, you can then show your dialog (restricted to the viewport, of course).
    If I want a window to pop up over anything else, I'll use native apps, not browser apps.
- pmarreck 7 months ago
  > 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
- acoyfellow 7 months ago
  I built this little tool to hack alert/confirm/prompt into promises.
  I use it everywhere. Optkit.com
- cosmic_cheese 7 months ago
  > 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.
- dehrmann 7 months ago
  > comnpletely unstyled
  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 7 months 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 7 months ago
    It can be styled with css.
    Edit: Example: https://gist.github.com/fzzzy/f5f1af66ee8fff478ffb3698ac9f80...
    - 7 months ago
  - nitwit005 7 months ago
    You can style it normally. They just don't like the default style.
    - stevage 7 months ago
      Yeah I don't get this complaint. So before they had to implement behaviour and styling. Now they just do the styling and get a semantic element too.
- christophilus 7 months ago
  > was hoping that [the implement wouldn’t suck]
  Yep. Welcome to the wonderful world of web standards.
- stevage 7 months ago
  > no-one wants an unmovable popup or modal-dialog that completely obscures the user's view of an underlying document
  Eh, I beg to differ. Lots of use cases for that kind of dialog, for saving, confirming changes, etc etc.
  - DaiPlusPlus 7 months ago
    > confirming changes
    ...how can I confirm a set of changes if the popup is blocking my view of said changes?
    - _0x168 7 months ago
      The popup can summarize the changes. For instance, "are you sure you want to delete X?"
    - stevage 7 months ago
      And yet, that pattern has worked just fine for decades.
    - rat9988 7 months ago
      Then don't confirm them if you aren't sure you wanted to confirm. The dialog is here to alert that you did click on confirm and it seems to me you weren't ready yet, so it did its job.
lapcat 7 months ago
See my article "The HTML dialog element API is a mess": https://lapcatsoftware.com/articles/2024/2/1.html
- apsurd 7 months 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 7 months 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 7 months 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-440405...
    - magicalist 7 months 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 7 months 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.
- AlienRobot 7 months 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 7 months 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 7 months 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.
- benatkin 7 months 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 7 months 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 7 months 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) but it seems useful for simple stuff.
pier25 7 months 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/
[2] https://mdn.github.io/dom-examples/popover-api/
[3] https://open-ui.org/components/popover-hint.research.explain...
somishere 7 months 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 7 months 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 7 months 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 7 months 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 7 months ago
  This is coming with invokers.
  https://css-tricks.com/invoker-commands-additional-ways-to-w...
pkphilip 7 months 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 7 months 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.
andypants 7 months 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 7 months 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 7 months 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 7 months 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 7 months 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...
- AlienRobot 7 months ago
  Maybe you should file a bug on HTMX.
replete 7 months 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
- 7 months ago
- replete 7 months ago
  Surprised by the downvotes to be honest, it's relevant. It's okay, I hate cookie popups also.
  - skrebbel 7 months ago
    fwiw i'm surprised by the downvotes too (and upvoted it to compensate). that said, complaining about downvotes is usually frowned upon here.
Sateeshm 7 months ago
Normal close in most examples not working for me. Android Firefox
- Aachen 7 months 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
- codethief 7 months 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 7 months ago
    As the MDN article documents, you don't necessarily have to use JavaScript:
```HTML <form method="dialog"> <button>Close</button> </form> ```
- itishappy 7 months ago
  Same here. Chrome, Windows 10.
  Only the listeners added via JS seem to work correctly.
7 months ago
silverwind 7 months 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 7 months 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 7 months 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 6 months ago
      The point is it will be possible without a framework
poincaredisk 7 months 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.
srathi 7 months 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 7 months 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)
quantadev 7 months 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 7 months 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=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 7 months 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!
    - skrebbel 7 months ago
      "omnibar" is just chrome's slightly pretentious name for the address bar.
    - akira2501 7 months ago
      https://zapier.com/blog/add-search-engine-to-chrome/
- htunnicliff 7 months ago
  Thanks! I used it today and thought others might enjoy.
joshdavham 7 months 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.
troupo 7 months 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-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
- chrishtr 7 months ago
  The issues were fixed actually.
  https://github.com/whatwg/html/wiki/dialog--initial-focus,-a...
  https://github.com/whatwg/html/pull/8199
  - troupo 7 months 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)
    "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.
tanepiper 7 months 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-h...
- skrebbel 7 months 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?
7 months ago
palsecam 7 months 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.
- silverwind 7 months ago
  Use `.show()` instead of `.showModal()` and create your own backdrop.
- zachrip 7 months ago
  This is a feature
  - palsecam 7 months 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).
    - Sesse__ 7 months 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
7 months ago
ulrischa 7 months ago
Why is this on the front page? It is nothing special
- palsecam 7 months 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 about the “418 I’m a teapot” HTTP status code, also linking to MDN. It was nothing new neither.
- Mystery-Machine 7 months ago
  No idea. If it was the new `popover` attribute, I'd understand.
  https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
- rock_artist 7 months ago
  I guess because the complete standardization is new. The page says:
  > This page was last modified on Oct 29, 2024
  - cantSpellSober 7 months ago
    Which seems to simply add <dialog> to the docs for the `cancel` event
    https://github.com/mdn/content/commit/d2421d25d1676cc11b01cc...
    https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogE...
    (<dialog> has been around for a decade)
    - ulrischa 7 months ago
      That's what I mean
- stevage 7 months ago
  And yet it's getting plenty of discussion. I like items like that.
- 7 months ago