- <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.
> - 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), 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.
Wish 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.
Luckily I've never had to bother with supporting Safari, but isn't one of the only good things about dealing with it that customers generally update Safari relatively quickly?
I don't really understand the Safari release schedule myself (browser updates only seem to come with combined operating system updates?) so I don't know what's keeping users from updating their browsers. Are these Apple users all running vulnerable browsers for some reason?
I find it nice that Safari <15.4 is still considered a valid target for your company, given that its market share is about that of Firefox (https://caniuse.com/usage-table). Must be hell to develop for, though.
Perhaps the upcoming inclusion of non-Safari browsers on iOS will help users stuck on old versions of the OS use a normal browser so these problems can go away. Chrome and Edge manage to release monthly updates that almost everyone installs so hopefully that option comes available to iOS users as well.
1. How do you get away with not supporting the second-most popular browser? [1]
2.
> help users stuck on old versions of the OS use a normal browser
Funny, iOS tends to be upgraded further back (ie support older devices), and faster [2], than (say) Android [3], because Apple is aggressive about updating users.
This. Why is there not a billion devices using QQBrowser or something other obscure at place two? Mobile IMHO is different - not every website will work.
Which really sucks on iPads, because not real free adblockers, faulty SVG rending in safari for a project I ran two years ago, and less support for browser features (PWA features mostly, so classical web often kinda works) makes browsing the web with touch often easy, yet very hard, when something is broken or nagging.
Depends on the industry and use-case. Some line-of-business apps might be designed without caring about any mobile/responsive usage. Others might be meant to be used at a specific workstation that has a computer as part of it (for example, the app might be controlling some equipment), or in some other environment in which mobile usage makes no sense.
> 1. How do you get away with not supporting the second-most popular browser?
Quite easily: desktop SaaS web application; no Macs in the office and no interest in buying them specifically for iOS; no customers using Macs. Also, Safari works Well Enough (TM) for people not to complain about the minor CSS offsets and if they do they can always install Firefox. I don't work there anymore, but I doubt any customer will even try to switch to Macs in the next five years.
For my personal use cases: if my site doesn't work on Safari, I can't legally test it on any of my devices so I don't bother. Even Microsoft published a cross-platform browser, I'll care about Safari the moment I can apt-install safari-dev/winget install safari.
> Funny, iOS tends to be upgraded further back (ie support older devices), and faster [2], than (say) Android [3], because Apple is aggressive about updating users.
Yes, iOS updates devices faster. However, Chrome isn't tied to the OS.
I've said it before and I'll say it again: my perfectly good iPad 2 is useless despite its quite competent CPU purely because there are no browsers for it. Had it run Android, I could just install Chrome and use it for slower but quite usable browsing; with the Safari lockdown the device became useless.
You can't install an up-to-date version of Safari onto iOS 15 because of Apple's architecture decisions, despite iOS 15 still receiving plenty of other updates, which means you're restricted in features if you can't install the latest major upgrade.
Google decoupled WebKit from the system image years ago and has always allowed alternative browser engines like Firefox, which means you can install the latest version of Firefox on Android 5.0 (November 2014) or Chrome on Android 7.0 (March 2016), but not Safari 16 on iOS 8 (September 2014) or iOS 10 (September 2016). My Oneplus One (April 2014) still browses the web fine, and it's a mere budget device compared to something like an iPhone!
> 1. How do you get away with not supporting the second-most popular browser? [1]
Not speaking for the OP, but the internal tools I work on only supprt Chrome - you can only login to these systems using Single Sign On, which is only possible to login via Chrome (Google SSO). Makes devving loads easier!
Ran into this on nytimes.com. Ended up using the polyfill. The benefits of dialog are just too great to not use it. So much easier than using other modal libraries or rolling your own.
What 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.
Maybe it’s sarcasm? On the other hand, the new school does have it pretty good these days with the evergreen browsers, so it could be genuine lack of perspective. Webkit is stubborn and slow moving, but nothing like what we endured with IE, especially since polyfills were not a ubiquitous concept and checking for feature support at runtime was a kind of dark art. I shudder just thinking about user agent strings again. If anything, my daily dose of strange BS these days comes from imposed third-party SaaS vendors rather than browser interop even when accounting for older versions of Safari.
Most organizations with any sort of audit, insurance, or regulatory requirements do. Updating software is one of the most basic things covered by any security benchmark.
Maybe internally. If done externally, extorting your users to update their stuff, then it is clearly overstepping the boundaries. Creating awareness is good and necessary, but insisting on another entity, be it a user or another company doing something, because it is in your company's security benchmark, is inappropriate. Quickly silly things, that have no security benefit at all make it into that benchmark and are tried to be forced upon other entities. Suddenly a company will be interested in how you internally handle your SSH keys. Do you make new ones every 3 months? No sorry, every 4 months is too long for our security benchmark.
The possibility of something being done poorly doesn’t mean that it can’t be done more thoughtfully. For example, most banks will refuse to let you do online banking using IE6 or SSLv3 and pretty much everyone is okay with that because the risks are obvious.
That’s always the tradeoff you have to make since you’re balancing the benefits to the user and cost of development - customers do benefit if you can ship better things faster because you’re not held back by discontinued browsers. <dialog> might not be there quite yet but it’s close and if you already don’t support IE11 there’s an obvious appeal.
I think you've got a good point there. It would be good to come together at a table and discuss such things on an eye to eye level, between entities. Obviously not always possible for natural persons to all come together. Announcing things well ahead of time can go a long way, rather than suddenly dropping support from one day to the next.
What I would proprose then is, that companies should state their minimum security requirements to work with any other entity somewhere publicly available, so that it will not be something ad-hoc invented for some entity.
I have seen companies trying to treat smaller ones like some kind of supplicant entity, that one can push around and ask about interna, that could easily lead to the bigger company building a copy of the smaller company in a few months, since they got much more workforce to put to it, if they really wanted. Asking for things like "architecture diagrams". I am quite sure, that big companies will laugh you out of the room, if you asked them to provide same for their architecture.
If people can use the entire web in their eyes without having to update their browser (which they can because they haven't had to update yet) EXCEPT for my site, why am I so specially that they need to update specifically for me?
Bad UX. Or maybe you're in an industry where it is your job to secure users computers.
On a normal system you can update the browser but on iOS you are stuck with the one coming with the OS version you have, you can't really tell them to update their browser because that's not feasible (and yes it's a security risk but there's nothing you can do about it).
My 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.
It’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.
In the case of safari, upgrades are tied to OS updates, so upgrading may require updating the entire OS, and in the worst case might require the user to buy a new phone.
I have a newish MBP from 2018. It’s still fast as hell and reliable. I can’t upgrade the OS because it is not supported. I don’t use Safari, but I’m sure there are people out there using a perfectly fine computer that Apple has dropped support for.
As far as I can see, the only possibility for buying a new MacBook Pro in 2018 that can’t run Ventura is if you bought the MacBook Pro Retina (Mid 2015) model, which wasn’t discontinued until mid-2018. All the older MacBook Pros that can’t run Ventura were discontinued in 2017 or earlier:
I think Ventura not supporting a model released more than seven years beforehand is a reasonable cut-off point. But if there are people who want to use an older model with a newer browser, they can use Firefox or Chrome.
Is there a valid reason for this? Like their code not running on the hardware anymore or is it just for profit? Do you at least get security updates?
Some kid somewhere digs up a rock under gunpoint and we're expected to throw it out as soon as something shinier comes along, disgusting. It's because of companies acting like this we need regulations on support and right to repair.
Nope. Says it’s not supported when I try to install it. It doesn’t give a reason though. It’s a maxed out Intel unit from 2018, it’s not listed as a supported model for Ventura. When I get home I can get the model number.
Most shopping websites or social media come to mind. I use to work in airline web contracting and when doing work for certain countries' national airline booking systems we had to support ie6 until 2019 (gmail had dropped support in 2010 and Microsoft officially EOL'd it in 2016)
There are also government sites which really need to support all browsers since time immemorial because many people will access them from old and outdated devices.
> 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.
Completely agree. If we had HTML elements as stylable as CSS toolkits out of the box, we'd save a lot of HTML bloat, and there would be no reason that the styled versions wouldn't be keyboard navigable, support screen readers etc.
Looking at stuff like date picker at the moment, it's just not going to get used at all as-is.
Like 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.
Those 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?
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.
Sure, but is <dialog> going to work seamlessly with that if it isn't aware of positioning outside of the top layer?
It could be that it is, but this is just an example of the kind of relatively common case that these maligned libraries cover that the spec often doesn't acknowledge.
Seems to be Opera Mini at 1.1%, and IE adding up to around 0.6%, so no feature ever gets more than 98%. Also, the browsers that never support anything seem to be mostly desktop ones.
It'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).
Safari 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.
> 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.
This 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.
That'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).
Although 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%
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?
same here, it also bugs me when a language needs a framework then it needs a transpiler than an ide extension than a course to learn well how to align all ecosystem properly since standard not enough to give credit/satisfaction to all involved in dev :(
This is how we end up with insufferable things like type "number" inputs and alert and most of the other baked in things.
They're halfway to what you want but can't go further because everyone has slightly different needs and browsers are already complex enough without baking in prebuilt components for everything from data tables to carousels to modals to drop-down menus.
Also, the list of things that bug you that a language needs describes pretty much every programming language in existence.
> Also, the list of things that bug you that a language needs describes pretty much every programming language in existence.
The bit about ecosystem and the context on JavaScript makes me certain he meant external needs - in other words he'd like "batteries to be included". There are several languages that come with a lot of stuff out of the box.
This means there will only ever be one and a half web browsers, as it is now essentially impossible to build one that includes every single feature everyone has ever demanded from a development environment. The browser should be a dumb virtual machine, for the same reason that we shouldn't be hard-coding the latest version of Python into CPUs and then demanding firmware or even hardware updates to get a new language feature. I can sit down as a single person and build an emulator that runs every single program available a video game console and yet thousands of engineers and hundreds of millions of dollars can't build a fucking web browser anymore?! It is utter madness, and it is the fault of people like yourself :(.
Yes, and that has led to how many thousands of hours of developer time wasted building these things custom for their app (or trying to find some minimally invasive library to do it). Bring on the dialog element. Maybe we can get the ability to custom style select inputs next.
Maybe it’s good not to prevent scrolling. I have had many situations where there was a non-scrollable modal dialogue and the buttons were off-screen (my phone has a small screen). So the website became completely unusable.
It shouldn't necessarily prevent scrolling; but I'd expect scrolling the page behind the modal to keep the modal where it is in the viewport. That is, after all, how native modal dialog windows work.
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.
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.
This is the spec behaviour - the browser focus should immediately jump to the first focusable item in the page for accessibility reasons. (As I understand it, this is the norm for dialogs outside the browser.)
My understanding is that you should be doing two things here: firstly, dialogs shouldn't generally be scrollable by themselves (or if they are, the interaction buttons should be sticky so that they're always visible). Instead, if you've got long text (say T&Cs) that should be in a scrollable box of its own. This allows the user to see the whole dialog (interactions and all) at once. Secondly, if there is something that should take focus before the buttons do, then you should set autofocus on that element explicitly. So in this case, you'd wrap the long text in a scrollable div, and add an "autofocus" attribute to that div to ensure that keyboard based users will immediately jump to it and be able to scroll it with their keyboard.
Your "cannot use" is my "element has proper accessibility consideration for people who are viewing the dialog inside a webview that disables scrolling." With the buttons always starting in scrolled-into-view and in focus, those people can at least dismiss the modal!
I agree. The primitives should be general and extensible via JS/WASM and presentation should be customizable. Browsers can’t cover every specific use case.
Prebuilt, specific components should focus on providing utility for documents and forms.
The “details” tag is a good example. It has interactive utility, clear semantics, but is easily extensible and you can fully style it.
The text input tag, not so much. It’s for example difficult to extend into a typeahead/combobox with sensible UX and presentation without writing a whole buch of JS. And the story around accessibility isn’t clear either.
Listen I’m just one dude with a very shaky understanding of programming. I still want my website to be good, so all those functionalities are a great thing.
Plus, 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.
In 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!
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
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/
I like that it comes on top, stays in center, no checkbook & css stuff.
The 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.
You still have the issue of the z-index being relative to its parent, and not absolute. So depending on which element it is set, its effect would not be the same. It’s still a good practice to use constants, but I still often had difficulties to place elements relative to each others on the z-index.
You can use isolation: isolate to explicitly create a new stacking context now. It makes the code a bit clearer because position: relative is used for lots of different things.
Normally I just set z-index to 1. z-index is only relative to the parent so you can still have a z-index of 1 overflowing another z-index of 9000 because the parent of the latter has a lower z-index then its sibling: https://jsfiddle.net/ec5qp7n3/
Usually if I find that if I need to control more then one layer of stacking, I’m doing something that is unnecessarily complex, and the right solution is to go back and find a better design.
"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.
The person you were responding to said they use "position: fixed" so they don't have to worry about z-indexes, and I was explaining why that works. See sibling reply for the more technical explanation.
"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.
> 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.
The 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;
});
I 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.
Yeah, 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.
I 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.
Makes 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.
It'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.
> 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.
> 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.
I 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.
I would ask to save the state locally (while the tab/window is still open) but allow clicking outside to close the dialog. finding the hidden x or cancel is sometimes hard, but it's easy to click/tap outside the window.
While this is certainly an option, quite often users expect to start with a clean slate when they open a new dialog. In this case you can only pick one. Give the user an extra convenient way to dismiss the dialog, but doing so, risk surprising them when they open the dialog the second time.
Me, I opt for the no surprise and make sure the top x-mark is nice and clickable, as well as a cancel button after a submit button, and make sure the escape key also works for users with easy access to physical keyboards.
Well, 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.
<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.
- <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