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

61–70 of 160 posts

Re: <dialog>: The Dialog Element

#61

Post by replete »

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.

Dialog works well for the most part, with a couple of CSS kludges here and there for the older browsers but otherwise straightforward to deal with. It's a decent addition to the web platform, but after 20 years of this I would like to stop making custom multi select controls every couple of years. Native controls good.

[0]: https://github.com/replete/biscuitman

Re: <dialog>: The Dialog Element

#62

Post by apsurd »

troupo wrote: post #33
apsurd wrote: post #22

Earlier quoted context omitted.

I don't think anyone would say web-standards are excellent, well designed and well-managed. All the wonderful value is in that they are standard. The web is great in its ubiquity. Love the web! Sure it's a mess, how could it not be?! is a win here in my view, especially for internal admin tools, I don't want to care about the latest flavor of frontend insanity. I just want to save screen space and open content as mod…

> I don't think anyone would say web-standards are excellent, well designed and well-managed. and yet: > I don't want to care about the latest flavor of frontend insanity. Those not well managed, not well-designed and not-well managed standards somehow get a pass because that insanity is now a part of the browser? Do you know that Chrome argued that should be removed from the platform because it's a bad API with mult…

What I'm saying is that the goal of standards and cross-platform support across time is valuable. The "open web" is a good thing for humanity.

Work towards this goal is a huge shit show. And messy. But it's a good goal.

The flavor-of-the-month frontend insanity is not serving this "good thing for humanity" goal as I call it. It's all well-intentioned and I'm not looking a gift horse in the mouth. But it is different.

Re: <dialog>: The Dialog Element

#63

Post by quantadev »

akira2501 wrote: post #58
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!

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!

Re: <dialog>: The Dialog Element

#64

Post by troupo »

chrishtr wrote: post #52
troupo wrote: post #32

About two years year before was rushed into all browsers, it had been implemented only in Chrome, and Chrome devs suggested removal of completely. Reason? No consensus on multiple issues relating to accessibility and security: https://github.com/whatwg/html/pull/4184#issuecomment-440405... And then boom! It was shipped everywhere with none of the issues discussed or fixed. Why? My tiny conspiracy theory is because br…

The issues were fixed actually. https://github.com/whatwg/html/wiki/dialog--initial-focus,-a... https://github.com/whatwg/html/pull/8199

Fixed after dialog was rapidly pushed into production across all browsers.

- Argued that dialog should be removed: 2018

- Tried to force-remove confirm/prompt: mid-2021

- Dialog rushed into all browsers: March 8-14, 2022.

- The linked proposal for a fix: March 04, 2022

- Request for position on standard: Jan 18, 2023

- The proposal merged into the standard: Jan 26, 2023

- Implemented in browsers: ?? (Webkit is possibly July 2024: https://bugs.webkit.org/show_bug.cgi?id=250795)

"Actually"

Dialog was literally rushed into all browsers without bothering to fix the issues that plagued it for a decade. Some of them were fixed post-factum because now you couldn't ignore these issues.

Re: <dialog>: The Dialog Element

#65

Post by akira2501 »

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!

https://zapier.com/blog/add-search-engine-to-chrome/

Re: <dialog>: The Dialog Element

#66

Post by codethief »

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.

Re: <dialog>: The Dialog Element

#67

Post by spatley »

DaiPlusPlus wrote: post #46
ryandrake wrote: post #43

Earlier quoted context omitted.

I feel like every company's (different/contrasting) "design language" and their insistence on using it, ends up being yet another weird looking thing on my computer. I'd rather decide for myself the fonts, color scheme, look and feel, etc. for applications on my computer, and have applications be consistent and respect those preferences. Rather than have some artist I don't know 2,000 miles away from me simply decide…

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

Re: <dialog>: The Dialog Element

#68

Post by DaiPlusPlus »

stevage wrote: post #56
DaiPlusPlus wrote: post #49

Earlier quoted context omitted.

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

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.

Re: <dialog>: The Dialog Element

#69

Post by epcoa »

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…

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.

Post reply on HN