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

91–100 of 160 posts

Re: <dialog>: The Dialog Element

#91

Post by DaiPlusPlus »

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…

Seeing ChatGPT use `return new Promise(...` directly inside an `async function` makes me somewhat less apprehensive about the future.

Re: <dialog>: The Dialog Element

#93

Post by pkphilip »

I wish HTML supported a concept of a "" tag which will allow multiple pages to be defined in a single HTML file and which can be shown one at a time but without the look-and-feel of a dialog.

Each PAGE should be able to pull in common sections from the same page such as the header, sidebar, footer etc based on specific states selectable in each PAGE.

Yes, you can do the same thing with the current approaches by hiding and showing divs etc.. But if it were possible to support these approaches via specific tags in HTML it may help.

EXAMPLE:

   
     
    .. common javascript elements here
     
    
   ...
    
    
    ...
    
    
   ...
    
   
    
     
     
     
        .....
     
     
   
    
     
     
        .....
     
     
   
    
     
     
     
        .....

Re: <dialog>: The Dialog Element

#94

Post by divbzero »

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:

Re: <dialog>: The Dialog Element

#95

Post by rat9988 »

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?

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

#96

Post by ulrischa »

cantSpellSober wrote: post #31
rock_artist wrote: post #8

Earlier quoted context omitted.

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)

That's what I mean

Re: <dialog>: The Dialog Element

#97

Post by xp84 »

ryandrake wrote: post #43
thousand_nights wrote: post #35

Earlier quoted context omitted.

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

I feel like every company's (different/contrasting) "design language" and their insistence on using it, ends up being yet another weird looking thing on my computer. I'd rather decide for myself the fonts, color scheme, look and feel, etc. for applications on my computer, and have applications be consistent and respect those preferences. Rather than have some artist I don't know 2,000 miles away from me simply decide…

I think most of us here who aren't self-important "UX designers" (or branding consultants) would agree with you, but the decision makers responsible for most of the sites on the Web disagree/don't care what we'd like. They want their site to look identical on all platforms and browsers, and to have their "signature" design language, to heck with what users might expect. It's why you see stupid things like pixel-perfect clones of the iOS "switch" control brought to the Web.

So, anyway, if the `` is ever to have a chance at adoption, instead of the "div soup and 1000 lines of JS and CSS modal" we've had everywhere since 2008 or so, it really should be blank slate for the "UX Designer" who fancies themself a real artist can vomit their personal brand of "elegant but bold, minimalist, flat design" onto the DOM.

If it's not completely skinnable, they'll just keep insisting on building div soup modals forever.

Re: <dialog>: The Dialog Element

#98

Post by 8n4vidtmkvmk »

dylan604 wrote: post #37
thousand_nights wrote: post #35

Earlier quoted context omitted.

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

The native datepicker is weird, at least in Chrome. I was playing around with it, and if you give it milliseconds it will render a millisecond picker in intervals of 100. If you give it a nice round minute, then ms and s disappear from the UI. There's no attribute to control this.

I also want a non-local time picker. Let me specify a time that the server can properly interpret as a moment in time. i.e specify an offset somehow.

Re: <dialog>: The Dialog Element

#99

Post by jtwaleson »

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…

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 it: https://github.com/jtwaleson/wizard-engine

The neat thing is that we can program the complex logic of the wizard with the full power of the programming language. By making each screen in the wizard a function that has input parameters and a return value, we can treat it like any other function. Show the same screen 3x in a row? Use a for loop. Show a screen with input that depends on the output of the previous step? Just use a variable to store the results.

Re: <dialog>: The Dialog Element

#100

Post by 8n4vidtmkvmk »

pkphilip wrote: post #93

I wish HTML supported a concept of a " " tag which will allow multiple pages to be defined in a single HTML file and which can be shown one at a time but without the look-and-feel of a dialog. Each PAGE should be able to pull in common sections from the same page such as the header, sidebar, footer etc based on specific states selectable in each PAGE. Yes, you can do the same thing with the current approaches by hidi…

I think there have been some improvements to print stylesheets recently that let you do just that for printing, but not for the screen AFAIK.
Post reply on HN