The <Dialog> Element
developer.mozilla.org
developer.mozilla.org
- <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
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.
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.
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.
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.
[1] https://gs.statcounter.com/browser-market-share
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.
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!
E.g. in Germany desktop Firefox has roughly double the market share of Safari.
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!
Most users, not all. Either because they don't want to upgrade the OS or they can't.
I worked in the education industry for some years and a big issue were kids using old iPads.
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.
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.
Bad UX. Or maybe you're in an industry where it is your job to secure users computers.
I’m almost afraid to ask, but what do you think is a large team?
https://support.apple.com/en-sg/HT213264
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:
https://en.wikipedia.org/wiki/List_of_Mac_models#2015
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.
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.
Korea?
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.
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
The project is abandoned though. I lost interest in client-side routing and focused on fullstack (SSR + hydration).
Why, oh-why, can't browser vendors update the default styling for modern devices ?
Looking at stuff like date picker at the moment, it's just not going to get used at all as-is.
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.
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.
What does this even mean? I can write a component in any JS framework that uses the dialog element literally today.
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.
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.
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.
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.
* 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).
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
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?
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.
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.
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);
}Here in Firefox, it does not work.
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.
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/di...
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.
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.
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.
dialog {display:none}[1] NoScript for Firefox (incl. mobile) & Chrome-based desktop browsers: https://noscript.net/getit/
[2] Kill Sticky bookmarklet for all browsers including mobile: 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/
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.)
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.
Using CSS-in-JS we at least make constants so we can do stuff like: `const STICKY_HEADER_Z = TOOLTIP_Z + 1`.
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.
Also doesn't this mean you have to listen for scroll events this way and update the XY coordinates for things like dropdowns?
Also drop downs are "attached" to some element in the UI, and you probably want those menus to scroll with the page
This really needs an explanation
> 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....
It does seem to have something to do with interfering with automatic focus on the dialog when it pops up as a modal.
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.
> 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.
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;
});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.
More advanced <select> elements are what I'd like to see support for next.
on: <a href="item?id=34759527">The <Dialog> Element</a>
(This is related to a change I made a month or two ago.)
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.
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.
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.
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.
I run into the modal/no modal thing just a day ago.
<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.
But now - UI elements are getting into HTML and at this point, it seems right. I'm not sure about the future.