Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

: The Dialog Element

developer.mozilla.org

Post reply on HN
Print view View original

111–120 of 160 posts

Re: <dialog>: The Dialog Element

#111

Post by andypants »

Andrex wrote: post #40
andypants wrote: post #16

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.

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

Re: <dialog>: The Dialog Element

#112

Post by [deleted] »

replete wrote: post #61

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

[deleted]

Re: <dialog>: The Dialog Element

#113

Post by Digit-Al »

quantadev wrote: post #55
zamalek wrote: post #13

Earlier quoted context omitted.

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

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

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.

Re: <dialog>: The Dialog Element

#114

Post by replete »

replete wrote: post #61

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

Surprised by the downvotes to be honest, it's relevant. It's okay, I hate cookie popups also.

Re: <dialog>: The Dialog Element

#115

Post by mikae1 »

divbzero wrote: post #94

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:

> Media players with controls:

>

>

Which look different in every single browser and can't be styled without JavaScript. Wish these were implemented better.

Re: <dialog>: The Dialog Element

#116

Post by Aachen »

Sateeshm wrote: post #5

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

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

Re: <dialog>: The Dialog Element

#117

Post by Aachen »

srathi wrote: post #17

Ublock origin is not able to filter out 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?

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)

Re: <dialog>: The Dialog Element

#118

Post by esrauch »

vintermann wrote: post #110
divbzero wrote: post #94

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.

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

Re: <dialog>: The Dialog Element

#119

Post by nikodotio »

vintermann wrote: post #110
divbzero wrote: post #94

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.

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.

Re: <dialog>: The Dialog Element

#120

Post by porridgeraisin »

nikodotio wrote: post #119
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.

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.

How do you use audio/video consistently across browsers? It looks quite different across the browser/platform combination matrix.
Post reply on HN