10 ms·
The <Dialog> Element
- djbeadle 4y agoSupported on all major browsers and 93% of total users according to caniuse.com https://caniuse.com/?search=dialog https://caniuse.com/?search=dialog
- Raed667 4y agonow go convince a product-manager that it is fine that 7% of the users can't see the login dialog.
- stocknoob 4y ago93% of users; what % of revenue?
- Raed667 4y agoI have yet to work at a company that provides a dashboard that shows revenue by browser features
- 1123581321 4y agoWe had this set up in 2014. Unfortunately, it was used to justify supporting ie8 as long as possible.
- LAC-Tech 4y agoSounds like a case of "be careful what you wish for, it might just come true!"
- baq 4y agoDon’t forget to set up the cost next to revenue if you go this way, and let your security team know
- drbacon 4y ago100% if used for login. /s
- spiffytech 4y agoI've noticed that adoption frequently slows to a crawl at around 95% or so. E.g., the JS `await` keyword, which started rolling out in 2016, is at 95%. CSS Variables haven't reached 97%. Past some point, you'll be waiting indefinitely for incremental adoption, and that point comes at a lower percentage than I'm happy with.
- tomxor 4y agoIt's because of safari. Same problem used to be with IE where computers/OS were stuck with a specific version. Now the world has moved onto evergreen browsers which are no pinned to OS versions (except for Apple).
- philistine 4y agoApple upgrades the desktop version of Safari for two versions behind the current OS. It’s iOS that’s tied to the browser.
- alerighi 4y agoSafari is the new IE. From one point of view it's good that Apple still develops his browser and didn't choose to use Chromium like all the others (except Firefox), but from another to this day keeping up with all new web features and standard is not a simple thing. Safari usually is the last to implement modern web features.
- tomxor 4y ago> From one point of view it's good that Apple still develops his browser and didn't choose to use Chromium like all the others (except Firefox) Technically, sure, and I'm all for browser diversity... but i'm kind of tired of this comment because Apple barely put any work or money into webkit while being excessively profitable (and there are good "business" reasons for them not doing this). At this point it's just not excusable for Apple... The way to support browser diversity would be for Apple to fund webkit properly rather than keep it on life support, locking their OS to safari is not the healthy solution for the web, it's the healthy solution for the App store's bottom line.
- acdha 4y agoThis is a valid concern but it comes with the caveat that you have to measure actual user-base. For example, in this case that’s the stragglers using IE11 years after it being out of support. That might not be something you care about at all if you don’t support that for other reasons such as security, and if there’s a functional polyfill you might use that so the cost is shifted to the people who don’t upgrade. Above all, I’d check your own site data: Can I Use has to use public, global data for obvious reasons but you can see fairly different numbers based on what type of site you’re running.
- philistine 4y agoPerhaps it’s time to approach the problem differently. Here’s what I propose: If a new HTML element is not supported in browsers with broad usage *but* those browsers are deemed insecure and no longer supported, go ahead.
- MrJohz 4y agoThat's pretty common. The "browserslist" tool allows you to specify which features you want to support in terms of the browsers that support them, and the default is "> 0.5%, last 2 versions, Firefox ESR, not dead", supports all browser versions for which at least one of the following is true: * Have more than 0.5% market share * Is one of the last two released versions of that browser type * Is the Firefox LTS release, which presumably doesn't fit the previous two rows but is deemed useful and modern enough to support. In addition, all "dead" browsers (any version of IE, and a handful of obsolete mobile browsers) are explicitly not supported. Of course, the browserslist string can be configured as needed, so if you know all users will be using a certain browser (say in a corporate environment) you can configure that fairly easily, and you can even use your own stats for things like the >2% queries. This string can be translated into a list of browsers, and then that list of browsers can be translated into a set of supported features, which you can use to warn developers if they use unsupported elements, or pass to the bundler so that only the relevant polyfills get included. There are also more advanced techniques (like building a modern and a legacy bundle which can be loaded as needed depending on the browser).
- fleddr 4y agoFor this there are polyfills.
- ketzu 4y agoAlthough a bit off topic, I think it is really interesting to see that a lot of firefox users are on an old version. Firefox supporting <dialog> has around 2.4% users, while firefox not supporting <dialog> because it is old, has around 0.7%
- rockwotj 4y agoWish I could use this, but Safari only started supporting this as of 15.4, which was released less than a year ago. I'll likely have to wait another 2-3 years until our site stops seeing these older Safari browsers. EDIT: looks like Firefox released support around the same time, but my company's Firefox users seem to be all be ok more recent versions.
- ec109685 4y agoSurely there is a polyfill you can use? https://github.com/GoogleChrome/dialog-polyfill https://github.com/GoogleChrome/dialog-polyfill
- colordrops 4y agoWhat sort of company do you work at where you can't prod your users to upgrade their browsers? Surely this is a security risk. I'm at a company of 100k employees and our small team has no problem telling users they need to upgrade.
- eyelidlessness 4y ago> 100k employees and our small team I’m almost afraid to ask, but what do you think is a large team?
- zrobotics 4y agoMy guess is they are a small internal team and their users are company employees. Otherwise, I can't imagine another scenario where that statement makes sense.
- CSSer 4y agoIt’s a bit odd though, because I’ve heard plenty of stories with those conditions where that’s still not true. One example is bank software that must run on IE11 because IT refuses to upgrade the equipment and security isn’t a priority because it’s airgapped or something silly like that.
- modeless 4y agoThe interesting thing about <dialog> is that it uses the "top layer" which always appears above everything else on the page regardless of z-index. So you can delete hacks like z-index:2147483647.
- rockwotj 4y agoHow do people normally manage z-indexes? I've found it's usually a mess of a people hard coding a bunch of values all over the place. Using CSS-in-JS we at least make constants so we can do stuff like: `const STICKY_HEADER_Z = TOOLTIP_Z + 1`.
- jeroenhd 4y agoSASS/SCSS helps. CSS variables would work too, but they're a but unwieldy and using tons of calc() isn't great for performance.
- devmunchies 4y agoI usually make modal position:fixed and use JavaScript to position them in the center or wherever. Same for drop-down menu’s when you click a button.
- rockwotj 4y agoHow does position:fixed help with the z-index? Also doesn't this mean you have to listen for scroll events this way and update the XY coordinates for things like dropdowns?
- Izkata 4y ago"position: fixed" removes the element from the layout and positions it relative to the window. You can scroll the page any which way and the element will stay where it is on the screen, making it a good choice to handle X/Y positioning of the modal.
- 4y ago
- Matheus28 4y ago> Warning: The tabindex attribute must not be used on the <dialog> element. This really needs an explanation
- Someone1234 4y ago"Why this is on MDN?" It is taken from the spec[0]: > The tabindex attribute must not be specified on dialog elements. Why is the spec like that? Uhh, I cannot find a source or explanation. If I had to GUESS, it is because it uses autofocus instead of tabindex to establish focus to the dialog when it is shown. [0]https://html.spec.whatwg.org/multipage/interactive-elements.html#the-dialog-element https://html.spec.whatwg.org/multipage/interactive-elements....
- Izkata 4y agoHere's a long conversation on it from 2016: https://github.com/whatwg/html/issues/1929 https://github.com/whatwg/html/issues/1929 It does seem to have something to do with interfering with automatic focus on the dialog when it pops up as a modal.
- dmitriid 4y agoThe only reason dialog suddenly shipped is because browsers want to remove alert/popup/confirm. Until last year the spec for dialog was in such a state that Chrome (the only ones implementing it) argued that it should be removed. IIRC literally none of the issues were fixed but suddenly it got shipped in all browsers.
- wizofaus 4y agoAnyone seeing that the topic tag for comments on this thread is truncated after the "The", presumably something to do with the < character?
- Mindless2112 4y agoon: <a href="item?id=34759527">The <Dialog> Element</a> Looks like the title is not properly escaped.
- dang 4y agoWhoops. Should be fixed now. Thanks! (This is related to a change I made a month or two ago.)
- userbinator 4y agoAt least this should theoretically make it easier to block those horrible popup modals, if they're all grouped under one element: dialog {display:none}
- zagrebian 4y agoNot a chance. The websites with the worst popups probably couldn’t care less about something like <dialog>. It’s all <div> and JavaScript for them.
- zrobotics 4y agoPlus, the worst offenders have a vested interest in making those hard to block. For example, my 2 common offenders are Twitter and reddit displaying modals on mobile prompting for app download. Both companies have no interest in making these easy to block.
- timeon 4y agoI click on most of those sites from search. So my fix is: cmd+w or ctrl+w.
- coldpie 4y agoIn the meantime, NoScript[1] frequently avoids popups entirely by just showing the page contents with no JS at all, and Kill Sticky[2] cleans up the pages that require JS to show you the content you actually want. As a bonus, it also nukes those stupid sticky headers! [1] NoScript for Firefox (incl. mobile) & Chrome-based desktop browsers: https://noscript.net/getit/ https://noscript.net/getit/ [2] Kill Sticky bookmarklet for all browsers including mobile: https://github.com/t-mart/kill-sticky https://github.com/t-mart/kill-sticky Or, a Firefox extension that adds a toolbar button: https://addons.mozilla.org/en-US/firefox/addon/kill-sticky/ https://addons.mozilla.org/en-US/firefox/addon/kill-sticky/
- crazygringo 4y ago+1 for Kill Sticky. I map a hotkey to it and I can't imagine using the web without it anymore. It kills every annoying modal and gives 100% of window height to content instead of annoying headers and footers. Between Kill Sticky and an ad blocker, it basically feels like using the web as it was originally intended. For content. (Also an extension to stop videos from auto playing, ever since that scourge started a few years ago.)
- transfire 4y agoMasters of convolution. > the returnValue property gets set to the value of the button that was used to save the form's state. So a more complex form will have to shove all its data into a single attribute for retrieval? Notice the example provide returns the favorite animal as “cancel” if you hit cancel.
- projektfu 4y agoYou should be able to access the form elements directly after the dialog is closed. The returnValue tells you which button was pressed.
- squeaky-clean 4y agoThe example is a bit weird though. Rather than accessing the form elements to get the data, it pushes it into the "value" property of the confirm button. So if you select an animal, returnValue is that animal, but if you click cancel, returnValur is "cancel". Which feels very clunky if you were to scale this behavior to any kind of complex form. I suppose the intention here was to show that it can be a dynamic value. // "Favorite animal" input sets the value of the submit button selectEl.addEventListener('change', (e) => { confirmBtn.value = selectEl.value; });
- projektfu 4y agoYeah, I agree. Looking at GitHub it's not very popular and hasn't developed an idiomatic style of use. Most of the uses I saw were homework assignments.
- runarberg 4y agoI agree. I’ve been using the <dialog> element at work for a few years now (with the polyfill). At first I experimented with using the returnValue, but as time went on I completely abandoned it in favor of just saving the form values in memory on confirm, and working with that. Basically I listen to the submit event of my <form method="dialog"> which I preventDefault, then I close the dialog with a value of "confirmed" and fire a custom "confirm" event with the form values as detail. As for dismissing the form (e.g. the top x-mark or a cancel button), I have a non-submit button which resets the form, closes the dialog with a value of the empty string. I also listen to the cancel event on the dialog (e.g. user presses the escape key) and run the same dismiss method. I guess my returnValue is therefor the empty string on cancel and a static "confirmed" on confirm, but honestly I’ve never actually used it outside of my initial experimentation when I felt like I should.
- davchana 4y agoI came across this element few weeks ago. Before this,I used to use a div with stuff, and javascript to show hide that div when required. E.g. Spanner icon in this page, lower left corner: https://spa.bydav.in/tsDMV/tsVerif.html https://spa.bydav.in/tsDMV/tsVerif.html Now, recently I used this dialog element with javascript & buttons to show hide div. E.g like Settings button at https://spa.bydav.in/weather/ https://spa.bydav.in/weather/ I like that it comes on top, stays in center, no checkbook & css stuff.
- mg 4y agoIt doesn't seem to prevent scrolling? https://jsfiddle.net/46nha7v3/ https://jsfiddle.net/46nha7v3/ I enjoy native elements when they are there. You can do really nice interactive trees with the <details> element for example: https://twitter.com/marekgibney/status/1593950777739218947 https://twitter.com/marekgibney/status/1593950777739218947 But I am not sure if it is a good idea to bake more and more of them into the browsers. Couldn't well made JavaScript modules provide the same functionality without making browsers more and more complex?
- AprilArcus 4y agoTry this: body:has(dialog[open]) { overflow: hidden } body:has(dialog[open])::before { content: ""; position: fixed; top: 0; left: 0; width: 100%; height: 100%; backdrop-filter: blur(4px); background-color: rgb(0, 0, 0, 0.5); }
- mg 4y agoHave you tried it? Here in Firefox, it does not work. https://jsfiddle.net/t34wz6kx/ https://jsfiddle.net/t34wz6kx/ Also, using "position: fixed" will fail when the dialog is longer than the screen. Then the user cannot read it all, and if the close button is at the bottom, they cannot close it.
- karlshea 4y agoFirefox also doesn't support :has. There's some more information on MDN [0] about how to make a modal dialog, you can open one in JavaScript using showModal() which has a backdrop, is actually modal, etc. [0]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog https://developer.mozilla.org/en-US/docs/Web/HTML/Element/di...
- mg 4y agoNice! https://jsfiddle.net/5gevzft8/1/ https://jsfiddle.net/5gevzft8/1/ Looks like you cannot use a button in the dialog then though. As it somehow makes the dialog scroll to the bottom.
- vxNsr 4y ago> It is important to provide a mechanism to close a dialog within the dialog element. For instance, the Esc key does not close non-modal dialogs by default, nor can one assume that a user will even have access to a physical keyboard (e.g., someone using a touch screen device without access to a keyboard). Well this is annoying as a user. Not being able to click away or use escape to close it feels like built in pop up that can’t be ignored.
- tgv 4y agoWell, you'll just have to add event handlers. And some styling. Just like before. I don't think this element is so great. It's an easy one if you've got a simple HTML document and you need to throw in a rarely used dialog, sure, but once you want to build a page with more interaction, you're going to end up with Vue, React, etc., for which better dialog components exist.
- pickpuck 4y ago> For instance, the Esc key does not close non-modal dialogs by default Modal dialogs are the ones that pop up on the screen and take over the main experience. Those come with escape key. I think you have to program the click-away with JavaScript however. Non-modal dialogs are uncommon, but basically they are more like menu pop-ups that can be ignored when open, so no need for escape key.
- runarberg 4y agoI was recently refactoring the dialogs at work where I inherited a codebase with a few different custom implementations of equally many dialogs. Some of those had the click outside handler closing the dialog, others didn’t. So I went outside to the world wide web to see how other apps do this to pick one consistent experience. What I saw is there is no consensus on whether clicking outside should close a modal dialog or not. A menu dialog, sure, but a modal dialog was all over the place. I went with not closing on outside press. My reasoning is that perhaps the user had filled up some form or done some other stateful interaction with the dialog’s content, and then clicked outside on accident (perhaps missed the submit button because their mouse was jerked around, or they are on a very small touch-screen) that would be annoying to have to reopen the dialog and re-enter those values.
- rado 4y agoTried to make it useful here: https://radogado.github.io/n-modal/ https://radogado.github.io/n-modal/
- wg0 4y agoIt seems like the <font> tag all over to me. No?
- pickpuck 4y agoInteresting! I'd say: <font> provides no structural or accessibility information. It was only there for styling purposes. <dialog> provides structural and accessibility information plus interactivity that previously required JavaScript. It comes with default styles but that's not the primary reason to use it.
- wg0 4y agoWhat I mean to say is that language itself had decorative elements at one point. Like font and friends. At that point, it seemed a reasonable idea. But now - UI elements are getting into HTML and at this point, it seems right. I'm not sure about the future.
- sam_goody 4y agoHow long has this been available (in Chrome/FF on desktop)?
- justsomeuser 4y agoMy notes on this: - <dialog>.showModal() is an indirect API to `top-layer`. - `top-layer` is kind of like a sibling to the root <html>, elements can be placed into the top-layer from any position in the existing DOM (it is like they have two positions). This allows co-locating your <dialog> next to the relevant elements in the tree. - There is only one `top-layer` but it can have many children. Last opened === current element on top. - Z-index has no effect in the top-layer. No need to compete for a higher z-index. - ::backdrop is a pseudo element that you can style behind the <dialog>. It is always below the last <dialog> opened. - Not supported in Safari <= 15.3
- danShumway 4y ago> - Z-index has no effect in the top-layer. No need to compete for a higher z-index. This is the kind of boring feature that can end up saving huge amounts of developer time. Z-indexing in CSS is kind of annoying and I've seen projects just detach dialogs from their normal position in the DOM entirely to get around stacking errors before. That obviously comes with its own set of problems... There are scenarios where you're still going to have to build custom controls, but a lot of my experience making dialogs has been frustration over these kinds of boring features -- "how do I get this to display on top and lock the page without writing a bunch of extra code and worrying about of edge cases?" ---- Minor question: > - There is only one `top-layer` but it can have many children. Last opened === current element on top. Is this true? The spec says: > The top layer is an ordered set of elements, rendered in the order they appear in the set. The last element in the set is rendered last, and thus appears on top. I'm still playing around with `dialog` elements, so you may well be right, I'm just having trouble finding the actual spec rules about what happens when there are multiple dialogs and they're being simultaneously manipulated. ---- > - Not supported in Safari <= 15.3 Worth noting that there is a polyfill (https://github.com/GoogleChrome/dialog-polyfill https://github.com/GoogleChrome/dialog-polyfill), but that the polyfill comes with some fairly large limitations, specifically that they don't advise dialogs be used as children of elements with their own stacking context. This is reasonable, but also... my first thought when I originally ran into `dialog` was "finally I can stop worrying about which of my elements create new stacking contexts!" -- so it does decrease the usefulness quite a bit.
- zelphirkalt 4y ago> The native HTML <dialog> element should be used in creating modal dialogs as it provides usability and accessibility features that must be replicated if using other elements for a similar purpose. Use the appropriate .showModal() or .show() method to render dialogs. If creating a custom dialog implementation, ensure all expected default behaviors are supported and proper labeling recommendations are followed. Any bets how long it will take JS frameworks to catch up to default behavior? Many websites still do not manage to properly make the back and forward button work, even after years. I am glad, that more semantic elements made it into HTML, reducing the amount of stuff needed to make simple things. I only wish, that we used the standard more.
- pier25 4y ago> Many websites still do not manage to properly make the back and forward button work, even after years. Yeah. Many (most?) JS client-side routers don't allow you to change the URL without reloading the current route, reset scroll, etc. I started working on a toy router for Svelte precisely to fix this behavior. https://github.com/PierBover/roots-svelte-router https://github.com/PierBover/roots-svelte-router The project is abandoned though. I lost interest in client-side routing and focused on fullstack (SSR + hydration).
- cush 4y agoLike most things in the js ecosystem, it likely never will. It'll be a best effort, chasing the standard with usability and accessibility gaps littering even the best libraries. But hey, there's rounded corners that glow, so totally worth it.
- interstice 4y agoThose libraries often cover edge cases the spec doesn't. For example with this what if for some reason I need the top level to share a some permamently available UI element?
- ddulaney 4y agoJust use iframes! But more seriously, you do this in multi-page apps by just having that UI element in every page. Just about any (server-side) templating system lets you do that easily.
- werdnapk 4y agoI replaced all uses of 3rd party dialogs with this native version in all my client projects (who's browsers support this feature) last year. Works well and that extra code is now gone. More advanced <select> elements are what I'd like to see support for next.
- runarberg 4y agoRelated: <selectmenu> https://open-ui.org/prototypes/selectmenu https://open-ui.org/prototypes/selectmenu
- mock-possum 4y agoCrazy how you can just do this with a native web component and use it in any modern browser without any library or package or transpiling or anything.
- ofirg 4y agoMaybe someone can explain the reason why the imperative and the declarative way of controlling the open state works differently. I run into the modal/no modal thing just a day ago.
- aliqot 4y agoMakes me wonder, the more JS functionality creeps into html and css, the less we need JS. I'm curious if that's an acknowledged future that these consortiums and working groups are headed toward, even if unspoken.
- albrewer 4y agoIt's a pretty common pattern to make a platform with scripting to fill in all the use cases not covered, then add the most commonly scripted behaviors and patterns to the platform.
- deleted 4y ago[deleted]