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

81–90 of 160 posts

Re: <dialog>: The Dialog Element

#81

Post by ivanjermakov »

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…

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

Re: <dialog>: The Dialog Element

#82

Post by stevage »

DaiPlusPlus wrote: post #68
stevage wrote: post #56

Earlier quoted context omitted.

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.

Re: <dialog>: The Dialog Element

#83

Post by lapcat »

AlienRobot wrote: post #74
lapcat wrote: post #2

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

>Last year the major web browser vendors decided to change the standard (remember, HTML is now a "living standard") SIGH... To be honest, I think it's unlikely you will ever try to open the same dialog modally twice. If you need user input to open the dialog, and a modal dialog blocks user input, the only way for this to happen is if you have an input on the dialog that opens the dialog. If you are using asynchronous…

> To be honest, I think it's unlikely you will ever try to open the same dialog modally twice.

This is a strange reaction to the blog post, because as you read, it's a certainty that my code did try to open the same dialog modally twice. This was a bug, of course, which would have been revealed in development if not for the change in the standard.

Re: <dialog>: The Dialog Element

#84

Post by salzig »

chrishtr wrote: post #51
thousand_nights wrote: post #35

Earlier quoted context omitted.

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

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

Re: <dialog>: The Dialog Element

#85

Post by simonw »

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

Re: <dialog>: The Dialog Element

#86

Post by pwg »

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

And, within three seconds of release, a 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.

Re: <dialog>: The Dialog Element

#87

Post by htunnicliff »

quantadev wrote: post #57

I'm really glad you posted this 'htunnicliff', because I'm manually maintaining a 'stack' of Dialog elements, along with an associated full-bleed 'background' overlay to block mouse clicks outside the dialog, and it will be really nice if I can get this (dialog element) to work and replace my code with something simpler. I'm assuming dialog elements can overlay other dialog elements!! I'll try!

Thanks! I used it today and thought others might enjoy.

Re: <dialog>: The Dialog Element

#88

Post by cosmic_cheese »

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…

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

Re: <dialog>: The Dialog Element

#89

Post by somishere »

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 state with CSS or a targeted button?

Would love to learn I'm wrong about this.

Re: <dialog>: The Dialog Element

#90

Post by DaiPlusPlus »

spatley wrote: post #67
DaiPlusPlus wrote: post #46

Earlier quoted context omitted.

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