Live data from Hacker News

: The Dialog Element

developer.mozilla.org

31–40 of 160 posts

Re: <dialog>: The Dialog Element

#31
post #3

Why is this on the front page? It is nothing special

I guess because the complete standardization is new. The page says: > This page was last modified on Oct 29, 2024

Which seems to simply add to the docs for the `cancel` event

https://github.com/mdn/content/commit/d2421d25d1676cc11b01cc...

https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogE...

( has been around for a decade)

Re: <dialog>: The Dialog Element

#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 browsers are hellbent on removing "legacy" APIs like confirm/prompt, and Chrome tried to remove it about half-a-year to a year before was suddenly shipped everywhere: https://dev.to/richharris/stay-alert-d

Re: <dialog>: The Dialog Element

#33
post #22
post #2

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

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 multiple issues? https://github.com/whatwg/html/pull/4184#issuecomment-440405...

Re: <dialog>: The Dialog Element

#35

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 of how much html/css purists want that to be the case

unless that is fixed, it will never happen

Re: <dialog>: The Dialog Element

#36

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…

> was hoping that [the implement wouldn’t suck]

Yep. Welcome to the wonderful world of web standards.

Re: <dialog>: The Dialog Element

#37

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 most commonly used element that I use is the date picker. i hate using it, but i'm not loading some library or framework just for it either.

Re: <dialog>: The Dialog Element

#38

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…

There are some efforts being made on the styling front by a W3C Community Group: https://open-ui.org/

Re: <dialog>: The Dialog Element

#39

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…

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

Re: <dialog>: The Dialog Element

#40

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?

Post reply on HN