: The Dialog Element • Hacker News Board

Re: <dialog>: The Dialog Element

#131

Post by skrebbel » Sat, Dec 07, 2024, 5:22 PM UTC

quantadev wrote: post #63

akira2501 wrote: post #58

Earlier quoted context omitted.

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

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!

"omnibar" is just chrome's slightly pretentious name for the address bar.

Re: <dialog>: The Dialog Element

#132

Post by pests » Sat, Dec 07, 2024, 5:44 PM UTC

esrauch wrote: post #118

vintermann wrote: post #110

Earlier quoted context omitted.

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.

Except file, no one is giving the browser full access to their files so that it can render a shitty file picker

The browser already has full access to their files.

Re: <dialog>: The Dialog Element

#133

Post by moffkalast » Sat, Dec 07, 2024, 5:51 PM UTC

lapcat wrote: post #2

See my article "The HTML dialog element API is a mess": https://lapcatsoftware.com/articles/2024/2/1.html

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.

Re: <dialog>: The Dialog Element

#134

Post by lowercased » Sat, Dec 07, 2024, 5:53 PM UTC

zelphirkalt wrote: post #103

jtwaleson wrote: post #99

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 don't think I've ever seen an example of it used that way in any tutorial, blog, or project documentation ever.

Re: <dialog>: The Dialog Element

#135

Post by quantadev » Sat, Dec 07, 2024, 5:58 PM UTC

zelphirkalt wrote: post #102

quantadev wrote: post #80

Earlier quoted context omitted.

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.

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.

Re: <dialog>: The Dialog Element

#136

Post by extra88 » Sat, Dec 07, 2024, 6:04 PM UTC

somishere wrote: post #121

Heliodex wrote: post #109

Earlier quoted context omitted.

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…

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.

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

Re: <dialog>: The Dialog Element

#137

Post by extra88 » Sat, Dec 07, 2024, 6:08 PM UTC

andypants wrote: post #111

Andrex wrote: post #40

Earlier quoted context omitted.

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

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.

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

Re: <dialog>: The Dialog Element

#138

Post by extra88 » Sat, Dec 07, 2024, 6:10 PM UTC

codethief wrote: post #66

Sateeshm wrote: post #5

Normal close in most examples not working for me. Android Firefox

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.

As the MDN article documents, you don't necessarily have to use JavaScript:

```HTML Close ```

Re: <dialog>: The Dialog Element

#139

Post by poincaredisk » Sat, Dec 07, 2024, 6:19 PM UTC

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

Re: <dialog>: The Dialog Element

#140

Post by Sophira » Sat, Dec 07, 2024, 6:23 PM UTC

DaiPlusPlus wrote: post #4

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 was also hoping that, because open 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.