Live data from Hacker News

: The Dialog Element

developer.mozilla.org

101–110 of 160 posts

Re: <dialog>: The Dialog Element

#101
post #76

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

Once we can use popover and anchor positioning, tooltips and drop downs can also be in the top layer. I can’t wait

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.

Re: <dialog>: The Dialog Element

#102
post #69

Earlier quoted context omitted.

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 inva…

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.

Re: <dialog>: The Dialog Element

#103
post #85

Earlier quoted context omitted.

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-4f46…

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…

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.

Re: <dialog>: The Dialog Element

#104
post #95

Earlier quoted context omitted.

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

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.

Re: <dialog>: The Dialog Element

#105

Earlier quoted context omitted.

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…

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.

Re: <dialog>: The Dialog Element

#106

Earlier quoted context omitted.

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…

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.

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.

Re: <dialog>: The Dialog Element

#107

I started using 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 element is that it's comnpletely unstyled, beyond a very basic (and very un-Chrome-like) thick black line pixel border…

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

I use it everywhere. Optkit.com

Re: <dialog>: The Dialog Element

#109

I love the 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 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 sta…

This is why I mainly use some other custom 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 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.

Re: <dialog>: The Dialog Element

#110

Other delightfully interactive HTML elements include… File pickers: Color pickers: Date/time pickers: Numeric sliders: Suggested options for text fields: Summaries with expandable details: FAQs Why are interactive HTML elements cool? They’re lightweight and semantic! Will the previous answer close when I open this one? Yes, because the &lt;details&gt; elements share the same name. Media players with controls:

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.
Post reply on HN