: The Dialog Element • Hacker News Board

Re: <dialog>: The Dialog Element

#51

Post by chrishtr » Fri, Dec 06, 2024, 10:36 PM UTC

thousand_nights wrote: post #35

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…

> 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

Re: <dialog>: The Dialog Element

#52

Post by chrishtr » Fri, Dec 06, 2024, 10:40 PM UTC

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

Re: <dialog>: The Dialog Element

#53

Post by magicalist » Fri, Dec 06, 2024, 10:51 PM UTC

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…

> Do you know that Chrome argued that should be removed from the platform because it's a bad API with multiple issues?

That's not at all what the comment you linked to says. It says there was an open question about if should be removed from the spec because interest hadn't materialized from Firefox and Webkit for the element after four years (and wouldn't for another two years after that).

Re: <dialog>: The Dialog Element

#54

Post by _0x168 » Fri, Dec 06, 2024, 10:51 PM UTC

DaiPlusPlus wrote: post #49

stevage wrote: post #39

Earlier quoted context omitted.

> no-one wants an unmovable popup or modal-dialog that completely obscures the user's view of an underlying document Eh, I beg to differ. Lots of use cases for that kind of dialog, for saving, confirming changes, etc etc.

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

The popup can summarize the changes. For instance, "are you sure you want to delete X?"

Re: <dialog>: The Dialog Element

#55

Post by quantadev » Fri, Dec 06, 2024, 10:56 PM UTC

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…

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. Most websites are trivial and thus don't need dialogs at all but there are some which are full featured apps (like mine) where Modals are a critical thing to have.

Re: <dialog>: The Dialog Element

#56

Post by stevage » Fri, Dec 06, 2024, 11:00 PM UTC

DaiPlusPlus wrote: post #49

stevage wrote: post #39

Earlier quoted context omitted.

> no-one wants an unmovable popup or modal-dialog that completely obscures the user's view of an underlying document Eh, I beg to differ. Lots of use cases for that kind of dialog, for saving, confirming changes, etc etc.

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

Re: <dialog>: The Dialog Element

#57

Post by quantadev » Fri, Dec 06, 2024, 11:05 PM UTC

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!

Re: <dialog>: The Dialog Element

#58

Post by akira2501 » Fri, Dec 06, 2024, 11:08 PM UTC

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.

Re: <dialog>: The Dialog Element

#59

Post by [deleted] » Fri, Dec 06, 2024, 11:11 PM UTC

[deleted]

Re: <dialog>: The Dialog Element

#60

Post by berkes » Fri, Dec 06, 2024, 11:13 PM UTC

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…

As can be seen when attaching an image. When you have to look up something in another tab. I now have to first close the file picking modal, before I can use anything in the browser.

It might be Gnome/Firefox only, IDK. But this modal thing is very bad UX.

The alternative is also bad, TBH: where the file picker is now gone somewhere in the sea of open windows. Maybe the middle-ground, where the file-picker is "attached" to the one tab that opened it, and goes away once other tabs and window chrome is engaged, but I guess thats hard to do in a WM?