Hacker News Reader

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.

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

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.

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

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

I mean that's how alerts work on almost every other platform

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.

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.

I also went thru a phase years ago where I also claimed all dialogs should be modeless to free up users to do "anything at any time". But the problem with "anything any time" is that your state management becomes a nightmare, because you then have to start guarding against astronomically large numbers of ways users can create invalid states, create contradictory settings, or have the content of one dialog become invalid, because of work done in some other dialog etc.

Hallmark of good design is when the user is doing one thing at a time, and the dialog flow makes intuitive sense. Often being able to jump back to a prior dialog means you can then start a NEW branch of all the dialogs you've already opened (and that's confusing). Modals simplify not only the code, but the user experience.

Why would the state management get any more difficult? Any change a user would have input into a modal dialog only gets applied when that dialog is closed/done. Same can be done for any implementation using no modal dialog. You can have a "save changes" or whatever button that confirms the changes and only then they affect the state. There seems no inherent reason that it would become more complicated.

The problem comes about when closing dialogs (i.e. their state change) in random order leads to invalid state. If the user is in a process of doing something where `A` depends on `B` and `B` depends on `C`, etc, for example, you can't just let them say "I'm done with A now" (before B and C), when the flow REQUIRES input from B and C in order to be valid.

I know people can argue endlessly that no process step should ever REQUIRE input from some other step, but that's the same as saying "There's no such thing as a multi-step process" which is obviously an incorrect statement.

Like if I'm editing a new CMS record, and adding an attachment/file to it, what if I clicked "cancel" on the new record WHILE the upload Dialog is open? Sure you can rationalize your way around that, and think your way out of how that can work with modeless dialogs, but you're just creating lots of unnecessary work for yourself if you do.

Modal dialogs have been around literally forever (even before the web) because they're needed. It's a signal to the user that they MUST complete something before moving forward.

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.

Yeah everything theoretically could be done without dialogs, but the beauty of dialogs is that they can keep you from losing your place in what you're doing "behind" them, before they opened. Modal dialogs are less disorienting to users than just taking to some other "page", because they can tell what they're currently working on is still there behind the dialog.

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?

> 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

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.

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

Weird. I think the built in date picker is actually pretty nice.

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

In which browser and OS?

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.

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

"But we don't want to look like everyone else"

and/or making the website using the most modern design trends sets us apart and reinforces that we are a cutting edge company.

Right down to the Stablediffusion-generated corporate-memphis artwork

These are the same people who insist on having PDF copies of everything and sometimes PDF forms. Nobody ever designs custom PDF form styling to be different. I wonder why? /s

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.

Idk, personally I completely disagree. I don't want to theme every single app. I want them to be distinctive and I don't actually care about native look. What I care about is that they have a nice design (which is as subjective as it gets, I know) but more importantly that they are distinctive enough in terms of design. Now I don't want every app to have different shortcuts or whatever, but I don't want slack to look like discord for example. And I don't want to theme anything ideally.

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.

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

@starting-style support is quite good in all browsers, not just chrome. https://caniuse.com/?search=%20%40starting-style

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

Seeing ChatGPT use `return new Promise(...` directly inside an `async function` makes me somewhat less apprehensive about the future.

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.

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.

Indeed, just me being stupid for realizing it so late. Coming from Java and Python 2 I never really understood async/await properly and when I started to grasp it, it took me weeks to realize I could apply it to user interactions too.

I found that non-obvious too: in both Python and JavaScript I've always seen "await ..." as effectively a hack to enable concurrent execution via an event loop, where the hope is that you won't be waiting very long at all for a response.

Realizing that you could use it for user input - where your promise might not resolve for minutes or even hours - was a bit of a light bulb moment for me.

I don't think I've ever seen an example of it used that way in any tutorial, blog, or project documentation ever.

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.

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/

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

> I was also hoping that, because open <dialog> elements exist in a distinct top-level layer, that they might even able to escape the bounds of the browser viewport, which would provide real value to the end-user in a lot of places

And, within three seconds of release, a <dialog> with this ability would be misused by advertisers to bring back the old pop-up windows that all browser's block by default now, because of advertiser misuse.

Most websites have their own style they apply everywhere and would probably appreciate how styleable dialog is. Maybe a way to easily apply/remove default styles could satisfy everyone.

That's so different from my experience. When I first met <dialog>, I thought I understood its purpose (as a modal) was to block user input from reaching anywhere else on the page. I have no idea why would anyone want to use it non-modally, since you can just use a div for that.

Nevertheless, I was also let down by it because it turns out if your <body> has a scrollbar, scroll wheel events bubble. There is a CSS property to stop them from bubbling but it doesn't work!

> I was also hoping that, because open <dialog> elements exist in a distinct top-level layer, that they might even able to escape the bounds of the browser viewport, which would provide real value to the end-user in a lot of places

As a user, I would absolutely not want this. I appreciate being able to know which windows actually come from my browser and which are coming from a webpage.

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

> 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

I built this little tool to hack alert/confirm/prompt into promises.

I use it everywhere. Optkit.com

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

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

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

It can be styled with css.

Edit: Example: https://gist.github.com/fzzzy/f5f1af66ee8fff478ffb3698ac9f80...

You can style it normally. They just don't like the default style.

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.

> was hoping that [the implement wouldn’t suck]

Yep. Welcome to the wonderful world of web standards.

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

> confirming changes

...how can I confirm a set of changes if the popup is blocking my view of said changes?

The popup can summarize the changes. For instance, "are you sure you want to delete X?"

And yet, that pattern has worked just fine for decades.

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.

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.

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.

Famous example of how badly this works is Jira. Want to look something up in another ticket? Bad luck! You need to close that ticket, then open the other one, then memorize or copy the info you need, then close that ticket, then open the original one again. At that point you are better off circumventing the whole shit UI and clone the browser tab. Which ultimately leads to having a dozen browser tabs open that one needs to cleanup later. Add to that the general incredible sluggishness of Jira, and the massive amount of things loaded when you load any of its pages, and you have a recipe for the disaster that thing is.