The worst thing about `` is that modal ones are placed in the CSS "top layer" which obstructs portalled content like tooltips and dropdowns.
: The Dialog Element
71–80 of 160 posts
Re: <dialog>: The Dialog Element
#72I 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.
Use `.show()` instead of `.showModal()` and create your own backdrop.
Re: <dialog>: The Dialog Element
#73I 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 hoping that the browser itself would provide for a lot of the tedium involved in UI dialog dev-work in-general, especially for things like automaticallyt conforming to the host OS' conventions on dialog/window layout and placement
sadly this only reminds me of bad actors spoofing native dialog UI's to phish passwords and such
Re: <dialog>: The Dialog Element
#74See 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 tasks to open the dialog, then you probably should keep track of what is open and what is not.
The same thing would happen if you were doing it on Qt, for example.
Re: <dialog>: The Dialog Element
#75Tried 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.
Maybe you should file a bug on HTMX.
Re: <dialog>: The Dialog Element
#76The worst thing about ` ` is that modal ones are placed in the CSS "top layer" which obstructs portalled content like tooltips and dropdowns.
Once we can use popover and anchor positioning, tooltips and drop downs can also be in the top layer. I can’t wait
Re: <dialog>: The Dialog Element
#77I 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…
That's so different from my experience. When I first met , I thought I understood its purpose (as a modal) was to block user input from reaching anywhere else on the page. I have no idea why would anyone want to use it non-modally, since you can just use a div for that.
Nevertheless, I was also let down by it because it turns out if your has a scrollbar, scroll wheel events bubble. There is a CSS property to stop them from bubbling but it doesn't work!
Re: <dialog>: The Dialog Element
#78Regardless of the implementation I think this was a step in the right direction.
There's a proposal in the works which is like a on steroids [1].
Also the Popover API [1] already in browsers for toast alerts. And a popover hint proposal for tooltips[2].
[1] https://open-ui.org/components/combobox.explainer/
[2] https://mdn.github.io/dom-examples/popover-api/
[3] https://open-ui.org/components/popover-hint.research.explain...
Re: <dialog>: The Dialog Element
#79Re: <dialog>: The Dialog Element
#80Earlier quoted context omitted.
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.
I also went thru a phase years ago where I also claimed all dialogs should be modeless to free up users to do "anything at any time". But the problem with "anything any time" is that your state management becomes a nightmare, because you then have to start guarding against astronomically large numbers of ways users can create invalid states, create contradictory settings, or have the content of one dialog become invalid, because of work done in some other dialog etc.
Hallmark of good design is when the user is doing one thing at a time, and the dialog flow makes intuitive sense. Often being able to jump back to a prior dialog means you can then start a NEW branch of all the dialogs you've already opened (and that's confusing). Modals simplify not only the code, but the user experience.