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

121–130 of 160 posts

Re: <dialog>: The Dialog Element

#121

Post by somishere »

Heliodex wrote: post #109
somishere wrote: post #89

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

This is why I mainly use some other custom with a popover="" attribute. They're easily targeted with a button and no clientside JS required, and can be closed by clicking outside them, which s don't have by default. They also still have the same helpful top-layer properties. Unsure about accessibility on this front, though it can't be worse than my previous attempts with hidden labels/checkboxes/form elements, while…

Re. accessibility, the main feature is that dialogs can be "modal" - meaning the rest of the page is non-interactive while the dialog is open - ensuring a focus trap.

Popovers are always non-modal, which can be problematic depending on the use-case. Of course it's possible to manually implement a focus trap, but it's complex and it's javascript.

Re: <dialog>: The Dialog Element

#122

Post by dv_dt »

vintermann wrote: post #110
divbzero wrote: post #94

Other delightfully interactive HTML elements include… File pickers: Color pickers: Date/time pickers: Numeric sliders: Suggested options for text fields: Summaries with expandable details: FAQs Why are interactive HTML elements cool? They’re lightweight and semantic! Will the previous answer close when I open this one? Yes, because the &lt;details&gt; elements share the same name. Media players with controls:

All of which these days are going to be unused in favor of some toolkit, because they don't behave predictably enough across browsers / browser versions.

Depends if you mean consistent to the os or browser or consistent to the js framework - I would suggest that most casual users don't notice and actually do better if its consistent to the os or browser they use

Well some other comment mentioned audio/video and those are seemingly aways different

Re: <dialog>: The Dialog Element

#123

Post by wongarsu »

dv_dt wrote: post #122
vintermann wrote: post #110

Earlier quoted context omitted.

All of which these days are going to be unused in favor of some toolkit, because they don't behave predictably enough across browsers / browser versions.

Depends if you mean consistent to the os or browser or consistent to the js framework - I would suggest that most casual users don't notice and actually do better if its consistent to the os or browser they use Well some other comment mentioned audio/video and those are seemingly aways different

> Well some other comment mentioned audio/video and those are seemingly aways different

Which is probably fine for your users. In every browser it plays video and has basic controls like a start/pause button, a timeline and a volume control. While the video is playing they even look identical: it's the video, playing; with controls only visible on hover.

The differences aren't an issue for the actual user, they are an issue for the designer that tries to have the website look and feel the same everywhere. Preferably look the same as it does on their MacBook.

Re: <dialog>: The Dialog Element

#124

Post by eek2121 »

vintermann wrote: post #110
divbzero wrote: post #94

Other delightfully interactive HTML elements include… File pickers: Color pickers: Date/time pickers: Numeric sliders: Suggested options for text fields: Summaries with expandable details: FAQs Why are interactive HTML elements cool? They’re lightweight and semantic! Will the previous answer close when I open this one? Yes, because the &lt;details&gt; elements share the same name. Media players with controls:

All of which these days are going to be unused in favor of some toolkit, because they don't behave predictably enough across browsers / browser versions.

I use them! I just add CSS to pretty them up.

Re: <dialog>: The Dialog Element

#125

Post by eek2121 »

eek2121 wrote: post #124
vintermann wrote: post #110

Earlier quoted context omitted.

All of which these days are going to be unused in favor of some toolkit, because they don't behave predictably enough across browsers / browser versions.

I use them! I just add CSS to pretty them up.

(not everyone is into using some hot new framework, some of use stick with HTML/CSS/JavaScript)

Re: <dialog>: The Dialog Element

#126

Post by gonzo41 »

divbzero wrote: post #94

Other delightfully interactive HTML elements include… File pickers: Color pickers: Date/time pickers: Numeric sliders: Suggested options for text fields: Summaries with expandable details: FAQs Why are interactive HTML elements cool? They’re lightweight and semantic! Will the previous answer close when I open this one? Yes, because the &lt;details&gt; elements share the same name. Media players with controls:

d is a gem. Love it.

Re: <dialog>: The Dialog Element

#127

Post by nikodotio »

porridgeraisin wrote: post #120
nikodotio wrote: post #119

Earlier quoted context omitted.

I use all of them pretty consistently! I try not to have them do magic, but using native date pickers and dropdowns and selects saves so much time and headache - and they work consistently.

How do you use audio/video consistently across browsers? It looks quite different across the browser/platform combination matrix.

I accept that they will look different but function consistently and in line with the client device - when that can be made as a design decision.

Re: <dialog>: The Dialog Element

#128

Post by svieira »

simonw wrote: post #85
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-4f46…

While they are nice, they don't block the event loop. That's definitely a feature you would need if you're aiming to replace `alert` and friends. As an alternative, yeah, that's a pretty reasonable API.

Re: <dialog>: The Dialog Element

#129

Post by skrebbel »

replete wrote: post #114
replete wrote: post #61

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

Surprised by the downvotes to be honest, it's relevant. It's okay, I hate cookie popups also.

fwiw i'm surprised by the downvotes too (and upvoted it to compensate). that said, complaining about downvotes is usually frowned upon here.

Re: <dialog>: The Dialog Element

#130

Post by skrebbel »

tanepiper wrote: post #108

The dialog tag is not a good idea - it can still be used to completely force a user into clicking and forcing an action they can't control https://tane.dev/2021/02/revisiting-dark-patterns-with-the-h...

I tried the stackblitz demo you linked to and I don't get it, why is "this element lets people author terrible user-hostile webpages" an indictment of the element? I mean you can make a user-hostile page with divs too. People won't be prevented from eg closing the tab, right?
Post reply on HN