[HN Gopher] <dialog>: The Dialog Element
___________________________________________________________________
<dialog>: The Dialog Element
Author : htunnicliff
Score : 118 points
Date : 2024-12-06 19:09 UTC (3 hours ago)
(HTM) web link (developer.mozilla.org)
(TXT) w3m dump (developer.mozilla.org)
| lapcat wrote:
| See my article "The HTML dialog element API is a mess":
| https://lapcatsoftware.com/articles/2024/2/1.html
| apsurd wrote:
| 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?!
|
| <dialog> 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 modal overlay on top of a main view.
| benatkin wrote:
| It isn't wonderful though, it's mediocre :)
|
| They should err on the side of keeping the APIs small. Maybe
| it would be better if Web Components weren't a thing. I
| thought ARIA was handling dialogs well when it comes to
| accessibility. I like the idea of splitting JavaScript into
| JSSugar and JS0. ( _It will be nice if in the Deno lawsuit
| that the USPTO clarifies that Oracle owns the term JavaScript
| and JS is a free-for-all._ )
| troupo wrote:
| > 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 <dialog> should be
| removed from the platform because it's a bad API with
| multiple issues? https://github.com/whatwg/html/pull/4184#iss
| uecomment-440405...
| magicalist wrote:
| > _Do you know that Chrome argued that <dialog> should be
| removed from the platform because it's a bad API with
| multiple issues?_
|
| That's not at all what the comment you linked to says. It
| says there was an open question about if <dialog> should be
| removed from the spec because interest hadn't materialized
| from Firefox and Webkit for the element after four years
| (and wouldn't for another two years after that).
| benatkin wrote:
| There's more where that came from. Google Chrome also did
| URLPattern, which I hope Chrome and Safari will hold firm on
| not supporting. The compression streams API wasn't bad, but
| it's a tiny API. I see a pattern here: Google sucks at UX and
| DX.
|
| Edit: I looked up _standards positions_ and both support
| URLPattern.
| lapcat wrote:
| > There's more where that came from. Google Chrome also did
| URLPattern, which I hope Chrome and Safari will hold firm on
| not supporting.
|
| Did you mean Firefox and Safari? Anyway, WebKit appears to be
| adding support for URLPattern.
| benatkin wrote:
| I did, and looked it up and Firefox chose the _support_
| position for it as well. I looked at the API again and I
| guess it 's all right. It doesn't help much with tree-based
| routing like Roda (https://roda.jeremyevans.net/index.html)
| but it seems useful for simple stuff.
| ulrischa wrote:
| Why is this on the front page? It is nothing special
| rock_artist wrote:
| I guess because the complete standardization is new. The page
| says:
|
| > This page was last modified on Oct 29, 2024
| cantSpellSober wrote:
| Which seems to simply add <dialog> to the docs for the
| `cancel` event
|
| https://github.com/mdn/content/commit/d2421d25d1676cc11b01cc.
| ..
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/HTMLDialogE...
|
| (<dialog> has been around for a decade)
| Mystery-Machine wrote:
| No idea. If it was the new `popover` attribute, I'd understand.
|
| https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
| palsecam wrote:
| It doesn't have to be brand new to be on the front page. Good
| ol' or reference content is suitable too.
|
| For instance, see this recent thread
| https://news.ycombinator.com/item?id=41967897 about the "418
| I'm a teapot" HTTP status code, also linking to MDN. It was
| nothing new neither.
| stevage wrote:
| And yet it's getting plenty of discussion. I like items like
| that.
| DaiPlusPlus wrote:
| I started using <dialog> 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 <dialog> element is that it's
| comnpletely unstyled, beyond a very basic (and very un-Chrome-
| like) thick black line pixel border with sharp edges. Whereas my-
| hope-and-expectation (and indeed: what got me interested in
| <dialog> in the first place) was that 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: I was hoping that I could
| mark-up an actual semantic model of a dialog and the browser
| would do the hard-work of making it look like a real native macOS
| (or iOS) - or Windows - dialog resource.
|
| I was also hoping that, because open <dialog> elements exist in a
| distinct top-level layer, that they might even able to escape the
| bounds of the browser viewport, which would provide real value to
| the end-user in a lot of places (e.g. no-one wants an unmovable
| popup or modal-dialog that completely obscures the user's view of
| an underlying document (like macOS's old "Sheets" dialogs) - so
| another false-hope of mine got popped that day.
|
| -----
|
| I get the feeling that browser vendors would all like to see us
| stop using `alert()`, `prompt()` and `confirm()` in JavaScript
| (because they block the JS/main thred), but the same browser-
| vendors really haven't come-up with an adequate replacement: the
| beeauty of alert/prompt/confirm is that their API is incredibly
| simple yet effective and also doesn't require the proggrammer to
| have any UI design-skills; I don't understand why browsers still
| don't offer a non-blocking Promie-based API for
| alert/prompt/confirm instead of them trying, in vain, to convince
| us that <dialog> is better in every situastion when it clearly
| isn't. ]
| mikae1 wrote:
| _> But my biggest let-down with the <dialog> element is that
| it's comnpletely unstyled_
|
| And it can't be styled without JavaScript? That's how it works
| with <audio>. So utterly frustrating.
| fzzzy wrote:
| It can be styled with css.
|
| Edit: Example: https://gist.github.com/fzzzy/f5f1af66ee8fff47
| 8ffb3698ac9f80...
| nitwit005 wrote:
| You can style it normally. They just don't like the default
| style.
| stevage wrote:
| Yeah I don't get this complaint. So before they had to
| implement behaviour and styling. Now they just do the
| styling and get a semantic element too.
| zamadatix wrote:
| Premade ways of escaping the bounds of a browser viewport with
| styling like a system dialog box certainly sounds like
| something a developer would want rather than users or browser
| makers. It's not an accidental disappointment new things aren't
| made to function like alert() and friends used to, it also has
| upsides (beyond just "the old interface was not promise based".
|
| I do agree <dialog> could have done with at least a little bit
| of TLC on the styling though, I just don't think it has to be
| 100% look and function like a system dialog outside the DOM to
| do it. Some base default styling to match the rest of the
| browser's default style would do wonders.
|
| For PWAs (or any "web apps with more permissions than a random
| page should get just for being loaded") I could see where you
| wanted <dialogs> to go as a more well received idea though,
| similar to how there are separate things for styling the
| windows and interacting with the system for those more
| privileged pages.
| zamalek wrote:
| Modals that blocks focus to an entire browser window aren't
| really a good idea (I'm of the opinion that they are _almost_
| always a shitty idea, but that 's harder to argue). People have
| multiple tabs open, and what if another tab contains
| information that your user needs to complete your dialog.
|
| You also have to be incredibly careful about how much visual
| control you allow over an actual dialog - especially making it
| look like the host OS. People get bamboozled by shitty in-
| browser fake virus alerts all the time, now add a real dialog,
| with real looks, that the user is forced to interact with, and
| you have a slam-dunk.
| tredre3 wrote:
| > Modals that blocks focus to an entire browser window aren't
| really a good idea (I'm of the opinion that they are almost
| always a shitty idea, but that's harder to argue).
|
| Good news then, because alert/prompt/confirm do not block the
| window in any modern browser!
|
| In Firefox it only blocks the viewport of the current tab, so
| it behaves exactly like a DIY modal. In Chromium browsers it
| does pop over part of the browser UI, but it still doesn't
| block the window; You interact with the tab bar, address bar,
| menu, etc.
| DaiPlusPlus wrote:
| > because alert/prompt/confirm do not block the window in
| any modern browser!
|
| Correct: they don't block the browser's desktop UI thread -
| but they do block the web-page's thread - and for abvout
| the past decade we can't move alert/prompt/confirm prompts:
| Chrome forces them to appear at the very top, dead-centre,
| and you can't scroll the page while it's open.
| KTibow wrote:
| Most websites have their own style they apply everywhere and
| would probably appreciate how styleable dialog is. Maybe a way
| to easily apply/remove default styles could satisfy everyone.
| thousand_nights wrote:
| > 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
| dylan604 wrote:
| 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.
| thousand_nights wrote:
| i don't know what context you're using it in, but imagine a
| company like airbnb or booking.com using the built in date
| picker on their front page
|
| you might as well cut their public valuation in half at
| that point. it's just not worth it to use the completely
| neglected and anemic components that are part of the
| browser, they are a joke
| WD-42 wrote:
| Weird. I think the built in date picker is actually
| pretty nice.
| dylan604 wrote:
| functionally it is perfectly fine. aesthetically, it
| looks nothing like any other component of the site's
| style. it very much looks like a band-aid
| ryandrake wrote:
| 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 what a dialog should look like (and it's always
| totally different than what some other artist decided a
| dialog should look like).
| DaiPlusPlus wrote:
| "But we don't want to look like everyone else"
| MrJohz wrote:
| I think you might be talking about a different thing to the
| other poster.
|
| The dialog element behaves exactly how you'd want it to
| behave for a company with their own design language -- you
| can style every part of it exactly how you need it (including
| the backdrop, the positioning and size of the dialog element
| itself, borders, colours, contents, etc). Depending on how
| you implement the design language, you can either apply those
| styles to the dialog element in general, or provide a custom
| component that wraps the dialog element and provides the
| styles you need.
|
| What the previous poster was complaining about was the
| opposite situation: they aren't working with their own design
| language, and instead want to use native-looking HTML
| elements (the default inputs, selects, buttons, etc).
| However, the dialog element does not provide a native look-
| and-feel, and instead is very minimalistic, providing only
| the base that developers can add their own styles to.
|
| That said, I think the browser implementors have made the
| correct choice here. The dialog element is not a native
| popup, and doesn't behave like a native popup at all, so it
| doesn't make sense to style it natively. In addition, the
| more styles they provide as part of the user-agent styling,
| the harder it is to reset those styles if you want to do
| something different. Apart from inputs, browsers fairly
| consistently stick with providing the minimum possible
| styling for an element to be usable, and this means that
| developers have the largest range of freedom to use those
| elements as they like.
| chrishtr wrote:
| The <dialog> element is fully styleable, including its
| backdrop (the MDN article explains how for the latter). In
| Chrome you can also fully style animations opening and
| closing a <dialog> or popover.
|
| https://developer.chrome.com/blog/entry-exit-animations
| christophilus wrote:
| > was hoping that [the implement wouldn't suck]
|
| Yep. Welcome to the wonderful world of web standards.
| pygar wrote:
| There are some efforts being made on the styling front by a W3C
| Community Group: https://open-ui.org/
| stevage wrote:
| > 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.
| DaiPlusPlus wrote:
| > confirming changes
|
| ...how can I confirm a set of changes if the popup is
| blocking my view of said changes?
| _0x168 wrote:
| The popup can summarize the changes. For instance, "are you
| sure you want to delete X?"
| Sateeshm wrote:
| Normal close in most examples not working for me. Android Firefox
| itishappy wrote:
| Same here. Chrome, Windows 10.
|
| Only the listeners added via JS seem to work correctly.
| palsecam wrote:
| I got an issue recently with how <dialog> interacts with AdSense
| "vignette" (interstitial) ads.
|
| Vignettes set their `z-index` CSS property to the max
| (2147483647), but a <dialog> is still higher on the z-plane (with
| no way to adjust that).
|
| So if you click a link from a <dialog>, and an interstitial gets
| displayed, it's _under_ the <dialog>. It looks like nothing
| happened, that clicking is broken.
|
| Fix in my case was to close() the <dialog> onclick.
| zachrip wrote:
| This is a feature
| palsecam wrote:
| Yes, but that can be surprising.
|
| That you cannot adjust the z-index is disturbing, especially
| given that you _have to_ style <dialog> yourself if you
| wanna make it look _any_ good (as others have reported here).
|
| Also, for the record, alert() is still higher than <dialog>
| on the plane (see https://i.imgur.com/tzKOEF2.png).
| Sesse__ wrote:
| FWIW, it's on a separate layer that's not affected by
| z-index:
|
| https://developer.mozilla.org/en-US/docs/Glossary/Top_layer
| andypants wrote:
| 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.
| apsurd wrote:
| Your last sentence is likely right, by default the form issues
| a network request.
|
| I've been using a dialog form to update an iframe (it's an
| editor) so it does work as normal the target iframe gets
| reloaded. It does not close the dialog though.
|
| I can't produce the case where hitting enter closes the dialog.
| It should be the same as `<button
| type='submit'>submit</button>` which also does not close the
| dialog.
|
| FWIW I learned yesterday that a button _can_ close the dialog:
| <button formmethod="dialog">Update & Close</button>
| Andrex wrote:
| > 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?
| srathi wrote:
| Ublock origin is not able to filter out <dialog> elements without
| breaking scrolling and other buttons in most cases (depending on
| how the site is implemented). Is there a generic way to disable
| these without affecting the rest of the site?
| troupo wrote:
| About two years year before <dialog> was rushed into all
| browsers, it had been implemented only in Chrome, and Chrome devs
| suggested removal of <dialog> 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 <dialog> was
| suddenly shipped everywhere: https://dev.to/richharris/stay-
| alert-d
| chrishtr wrote:
| The issues were fixed actually.
|
| https://github.com/whatwg/html/wiki/dialog--initial-focus,-a...
|
| https://github.com/whatwg/html/pull/8199
| joshdavham wrote:
| I still remember being confused about the differences between
| dialogs, popovers, and modal vs non-modal elements when I was
| first learning web development.
___________________________________________________________________
(page generated 2024-12-06 23:00 UTC)