The 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
: The Dialog Element
101–110 of 160 posts
Re: <dialog>: The Dialog Element
#102Earlier quoted context omitted.
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 inva…
Re: <dialog>: The Dialog Element
#103Earlier quoted context omitted.
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…
For a company that had a giant 30 minute wizard in the web interface, I wrote a wizard engine in VueJS that works similarly. It's served hundreds of thousands of users since 2019 and went through medical device certification :) Took me quite some time to realize we can use `await` to wait for user input too, not just APIs etc. I recently re-created parts of it from memory for a hobby project and just now open-sourced…
Re: <dialog>: The Dialog Element
#104Earlier quoted context omitted.
> confirming changes ...how can I confirm a set of changes if the popup is blocking my view of said changes?
Then don't confirm them if you aren't sure you wanted to confirm. The dialog is here to alert that you did click on confirm and it seems to me you weren't ready yet, so it did its job.
Re: <dialog>: The Dialog Element
#105Earlier quoted context omitted.
For a company that had a giant 30 minute wizard in the web interface, I wrote a wizard engine in VueJS that works similarly. It's served hundreds of thousands of users since 2019 and went through medical device certification :) Took me quite some time to realize we can use `await` to wait for user input too, not just APIs etc. I recently re-created parts of it from memory for a hobby project and just now open-sourced…
Why is it any surprise that one can use await to wait for user input? It is just promises under the hood, right? So that is exactly like one would expect a promise using dialog to work.
Re: <dialog>: The Dialog Element
#106Earlier quoted context omitted.
For a company that had a giant 30 minute wizard in the web interface, I wrote a wizard engine in VueJS that works similarly. It's served hundreds of thousands of users since 2019 and went through medical device certification :) Took me quite some time to realize we can use `await` to wait for user input too, not just APIs etc. I recently re-created parts of it from memory for a hobby project and just now open-sourced…
Why is it any surprise that one can use await to wait for user input? It is just promises under the hood, right? So that is exactly like one would expect a promise using dialog to work.
Realizing that you could use it for user input - where your promise might not resolve for minutes or even hours - was a bit of a light bulb moment for me.
Re: <dialog>: The Dialog Element
#107I 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 use it everywhere. Optkit.com
Re: <dialog>: The Dialog Element
#108https://tane.dev/2021/02/revisiting-dark-patterns-with-the-h...
Re: <dialog>: The Dialog Element
#109I 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…
Unsure about accessibility on this front, though it can't be worse than my previous attempts with hidden labels/checkboxes/form elements, while being much simpler and less hacky.
Re: <dialog>: The Dialog Element
#110Other 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 <details> elements share the same name. Media players with controls: