7 ms·

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 ver

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...
  - deleted 2y ago
    [deleted]
- nitwit005 2y ago
  You can style it normally. They just don't like the default style.
  - stevage 2y 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.
zamadatix 2y 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.
zamalek 2y 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 2y 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 2y 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.
    - saagarjha 2y ago
      I mean that's how alerts work on almost every other platform
- quantadev 2y 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.
KTibow 2y 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.
thousand_nights 2y 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
- dylan604 2y 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.
  - thousand_nights 2y 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
    - WD-42 2y ago
      Weird. I think the built in date picker is actually pretty nice.
      - dylan604 2y ago
        functionally it is perfectly fine. aesthetically, it looks nothing like any other component of the site's style. it very much looks like a band-aid
      - dotancohen 2y ago
        In which browser and OS?
christophilus 2y ago
> was hoping that [the implement wouldn’t suck] Yep. Welcome to the wonderful world of web standards.
pygar 2y ago
There are some efforts being made on the styling front by a W3C Community Group: https://open-ui.org/ https://open-ui.org/
stevage 2y 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 2y ago
  > confirming changes ...how can I confirm a set of changes if the popup is blocking my view of said changes?
  - _0x168 2y ago
    The popup can summarize the changes. For instance, "are you sure you want to delete X?"
  - stevage 2y ago
    And yet, that pattern has worked just fine for decades.
    - DaiPlusPlus 2y ago
      On a Windows or macOS desktop, the OS-provided MessageBox() can be freely moved around the screen - but that's not how in-web-page modals tend to work.
      - stevage 2y ago
        I don't find I have the problem you describe, because at worst you can generally abort the save or whatever and verify then redo it. The one that bugs me is online order forms that don't give you all your critical details like dates, and exactly what you are paying for, on one screen where you finally commit.
  - rat9988 2y 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.
pmarreck 2y 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
AlienRobot 2y 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!
ivanjermakov 2y 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/ https://textslashplain.com/2017/01/14/the-line-of-death/
simonw 2y 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 https://tools.simonwillison.net/prompts-js - code written by o1: https://chatgpt.com/share/67539c28-4df0-8006-b021-4f468e011fd9 https://chatgpt.com/share/67539c28-4df0-8006-b021-4f468e011f...
- DaiPlusPlus 2y ago
  Seeing ChatGPT use `return new Promise(...` directly inside an `async function` makes me somewhat less apprehensive about the future.
- jtwaleson 2y 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 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 2y 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.
    - 2y ago
pwg 2y 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.
cosmic_cheese 2y 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.
acoyfellow 2y ago
I built this little tool to hack alert/confirm/prompt into promises. I use it everywhere. Optkit.com
Sophira 2y 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 2y 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.
dehrmann 2y 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 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...
- deleted 2y ago
  [deleted]
nitwit005 2y ago
You can style it normally. They just don't like the default style.
- stevage 2y 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.

zamadatix 2y 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.

zamalek 2y 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 2y 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 2y 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.
  - saagarjha 2y ago
    I mean that's how alerts work on almost every other platform
quantadev 2y 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.

KTibow 2y 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.

thousand_nights 2y 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

dylan604 2y 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.
- thousand_nights 2y 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
  - WD-42 2y ago
    Weird. I think the built in date picker is actually pretty nice.
    - dylan604 2y ago
      functionally it is perfectly fine. aesthetically, it looks nothing like any other component of the site's style. it very much looks like a band-aid
    - dotancohen 2y ago
      In which browser and OS?

christophilus 2y ago

> was hoping that [the implement wouldn’t suck] Yep. Welcome to the wonderful world of web standards.

pygar 2y ago

There are some efforts being made on the styling front by a W3C Community Group: https://open-ui.org/ https://open-ui.org/

stevage 2y 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 2y ago
> confirming changes ...how can I confirm a set of changes if the popup is blocking my view of said changes?
- _0x168 2y ago
  The popup can summarize the changes. For instance, "are you sure you want to delete X?"
- stevage 2y ago
  And yet, that pattern has worked just fine for decades.
  - DaiPlusPlus 2y ago
    On a Windows or macOS desktop, the OS-provided MessageBox() can be freely moved around the screen - but that's not how in-web-page modals tend to work.
    - stevage 2y ago
      I don't find I have the problem you describe, because at worst you can generally abort the save or whatever and verify then redo it. The one that bugs me is online order forms that don't give you all your critical details like dates, and exactly what you are paying for, on one screen where you finally commit.
- rat9988 2y 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.

pmarreck 2y 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

AlienRobot 2y 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!

ivanjermakov 2y 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/ https://textslashplain.com/2017/01/14/the-line-of-death/

simonw 2y 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 https://tools.simonwillison.net/prompts-js - code written by o1: https://chatgpt.com/share/67539c28-4df0-8006-b021-4f468e011fd9 https://chatgpt.com/share/67539c28-4df0-8006-b021-4f468e011f...

DaiPlusPlus 2y ago
Seeing ChatGPT use `return new Promise(...` directly inside an `async function` makes me somewhat less apprehensive about the future.
jtwaleson 2y 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 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 2y 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.
  - 2y ago

pwg 2y 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.

cosmic_cheese 2y 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.

acoyfellow 2y ago

I built this little tool to hack alert/confirm/prompt into promises. I use it everywhere. Optkit.com

Sophira 2y 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 2y 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.

dehrmann 2y 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?