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

11–20 of 160 posts

Re: <dialog>: The Dialog Element

#11

Post by nitwit005 »

mikae1 wrote: post #6
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…

> But my biggest let-down with the element is that it's comnpletely unstyled And it can't be styled without JavaScript? That's how it works with . So utterly frustrating.

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

Re: <dialog>: The Dialog Element

#12

Post by zamadatix »

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…

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

Re: <dialog>: The Dialog Element

#13

Post by zamalek »

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…

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.

Re: <dialog>: The Dialog Element

#14

Post by palsecam »

I got an issue recently with how interacts with AdSense “vignette” (interstitial) ads.

Vignettes set their `z-index` CSS property to the max (2147483647), but a is still higher on the z-plane (with no way to adjust that).

So if you click a link from a , and an interstitial gets displayed, it’s under the . It looks like nothing happened, that clicking is broken.

Fix in my case was to close() the onclick.

Re: <dialog>: The Dialog Element

#15

Post by zachrip »

palsecam wrote: post #14

I got an issue recently with how interacts with AdSense “vignette” (interstitial) ads. Vignettes set their `z-index` CSS property to the max (2147483647), but a is still higher on the z-plane (with no way to adjust that). So if you click a link from a , and an interstitial gets displayed, it’s under the . It looks like nothing happened, that clicking is broken. Fix in my case was to close() the onclick.

This is a feature

Re: <dialog>: The Dialog Element

#16

Post by andypants »

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.

Re: <dialog>: The Dialog Element

#17

Post by srathi »

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?

Re: <dialog>: The Dialog Element

#19

Post by palsecam »

zachrip wrote: post #15
palsecam wrote: post #14

I got an issue recently with how interacts with AdSense “vignette” (interstitial) ads. Vignettes set their `z-index` CSS property to the max (2147483647), but a is still higher on the z-plane (with no way to adjust that). So if you click a link from a , and an interstitial gets displayed, it’s under the . It looks like nothing happened, that clicking is broken. Fix in my case was to close() the onclick.

This is a feature

Yes, but that can be surprising.

That you cannot adjust the z-index is disturbing, especially given that you have to style yourself if you wanna make it look any good (as others have reported here).

Also, for the record, alert() is still higher than on the plane (see https://i.imgur.com/tzKOEF2.png).

Re: <dialog>: The Dialog Element

#20

Post by tredre3 »

zamalek wrote: post #13
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…

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…

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

Post reply on HN