How Popovers Are About to Become a Whole Lot Easier to Build

So who has got popovers in their design system? Show of hands. Cool. The majority of this audience.

I only found out recently that in the US, Yorkshire Puddings are called popovers. I even found this video on America's text kitchen, where they say popovers can be real tricky as we're about to find out in this talk. They've got a custody inside. I can't promise that for today's talk.

Yeah, we'll be focusing on content overlaps other content. Super common, it wasn't always like that on the web, right? We had long blobs of linear content, and now we like to put stuff on top of other stuff. On some websites, they really go overboard with this, where you get like banners for, do you want to go send to cookies? Do you want to sign up for our thing? There's ads that are quite bad and invasive. And then sometimes, you even get more stuff on top of that. Like in this case, why? It's no good. It's no good, and you see a problem here in this example is that their modal to ask you to sign up for the newsletter is actually underneath the cookie consent thingy. Not good.

And yeah, you're probably aware of this website called ModalsModalsModals.com. It's modal with a z. It explains, in quite a lot of detail, why you should not be using modals, and that's something I won't be covering today. I'm not going to talk about why you should use them. I'm going to talk about if you are using them or if someone in your team decided were using them, how to build them well.

And the reason I got interested in this is that as of recently in HTML, we've got two exciting features that allow you to build popovers and dialogues quite well. A little bit of a spoil here, I'm not only going to talk about popovers but also about dialogues because they are quite similar, and I to leave this room with knowledge about how they're actually different.

So dialogue is an HTML element that has wide browser support that, as of recently, works really well accessibly as well. Like it's safe to use. There's still some stuff to iron out. There used to be a lot more accessibility issues with it, and it's quite safe to use now. And then there's popover, which is fairly new. But also, it's supported in Chrome and Edge, Safari, and it is in Firefox behind the flag. So very soon, we'll be able to use this. And I recommend actually experimenting with it today. There are still also some accessibility considerations to take into account.

I do have a blog post coming out about that soon because there is some stuff to look at there. Today, we'll talk about UI considerations for these things, and also semantics, which are really important, especially when you're thinking about both dialogues and popovers, how are these actually different? It's quite a challenge to find out.

Now, as mentioned, I'm Hedda. I work at NL Design System for the Dutch government. I'm a freelance developer-related accessibility person. And I'm also a participant in Open UI Community Group, which is a group at the W3C that makes things like popovers. So we're working on it there. I now have my own blog on Hedda.blog. You can like and subscribe. The other day, someone thought you could actually like and subscribe. You need to get the RSS feed. So that's something you can use.

So let's look at some examples of popovers. They are everywhere. I don't know if anyone's got the new Slack yet, but they do use a popover to explain to you how to use it. Teaching UI is what that's called. It's not always used in very good ways either. We've seen previous examples. When I was using Teams to chat to my colleague, I got this feedback popover that just popped over my content, my conversation that I was having. And the other day, when I was in a very serious business meeting, I got Microsoft to promote their other products in Microsoft Teams. They went, do you want to use Excel, because we also make that. I'm not sure, like, it was kind of in a way, because I was getting ready to have some very serious conversations there. And it goes even weirder sometimes. They also encouraged me to be my expressive self. Create some avatars. No, thanks. I'm in a serious meeting. There's better things like Slack that give you this popover that says, you look nice today. And they don't even check your camera footage for it. They actually tell you you look nice every single day, which I appreciate.

There are more serious things too. Like, in banking, you'll find popovers to do, like, combo boxes, date pickers, all these sorts of things. So lots of popovers exist across the web. And I want to look now at how these patterns are different, because some of these are dialogues and some of them are popovers. And many of them are both.

So let's look at what the differences are, starting with dialogue. So a dialogue is an additional window to your main window or a sub-window. One of the things I found out working on this is that there isn't one central definition. So I'll be giving you a couple to helpfully guide you there. Another definition is something that contains an action or a task or crucial information or critical information. It's often a conversation between you and the system. It will be things like do you want to continue, yes or no? Or if you're starting a new file, what do you want to do with the current one? All these kinds of things where you actually need to talk to the user and need to get their feedback immediately. So it is warranted to kind of interrupt them and go and ask those questions.

Now, to build dialogues, there is the dialogue element in HTML. And you can use it with scripts. I don't have any React examples in here, but you can port these to React, because it's all vanilla JavaScript. So when you find the element or you have a ref to the element, you can call show modal on a dialogue or you can call show. So show modal is going to show it as a modal, and show is going to show it as a non-modal. We'll get into the differences in a bit. So this one is important to talk about the word dialogue. So if you use the dialogue element, you get lots of stuff for free from the browser. So it will make it modal for you. It will do the keyboard stuff for you, and it will do a bunch of other things. That is different from using a role of dialogue on a div, because the role of dialogue is going to give you that semantic, but it's not going to give you any of the behaviors. And then that is also different from using just the word dialogue, which you might do in conversations with your colleagues. That is a different thing altogether. So you might be using a role of dialogue or even a dialogue element, but those are kind of different levels of using dialogue at work. Now dialogue is supported quite well across all the major browsers. And there used to be quite a big amount of accessibility issues, and there are a lot less now. And for more detail about that, I recommend Scott O'Hara's blog posts about them.

This most recent one used the dialogue element reasonably. Moving on from dialogues to popover, a popover is a floating piece of UI that's supplemental, contextual, and importantly, a non-modal dialogue. So with dialogue, you can make modal dialogues, with popover you can make non-modal dialogues. And they are also for transient content.

In HTML, they come in the form of an attribute, so not an element. And when you add that attribute to an element, it's going to add a bunch of behaviors, which could include like dismiss, keyboard, top layer presence, also closure of other popovers. It's going to deal with all of these kind of things for you. Now this is for elements that are on top of other page content that are not always visible and that are usually displayed one at a time. That's kind of how it was meant to be.

And it is actually being used by some people. This is from Chrome, a stat that is clearly going up. It's 0.3% of page loads in the Chromium-based browsers. And I don't know if you know this website called github.com, but they are using it in production at the moment. Experimenting with it, I believe, but they are using it now. So they have a manual popover. That means that they are triggering it with scripts because they make it work on Hover. So when you hover over icons and you get a little tool tip, that's a popover. In this screenshot, you see a menu right underneath. That's also a popover. And you can see that it appears in the top layer as well when you inspect it in the browser. It's also coming to Photoshop on the web. I don't know if you've seen, but they build all of Photoshop on the web. Pretty exciting. And they are also looking at using popover there. So popover is for content figures. It's for form element suggestions, for action menus, for list boxes, and as mentioned for teaching UI. So lots of different and very variety use cases there. This is how it works. Basically, if you have a button and a div and the div is your popover, what you can do is add the popover attribute. And in React, in JSX, you'll have to give it some value so you can give it the empty string as a value.

Then when you add an ID to it and you give popover target equals that ID on the button, this is now working popover. The button is going to toggle the popover for you. That's pretty cool. It works without JavaScript. I know I'm at the React Conference and we are all about JavaScript here, but it's a really cool opportunity to reduce your bundle sizes because where before maybe you would need to run some scripts, now the browser will take care of it for you and will take care of lots of other stuff while it's at it. And that's pretty cool.

In fact, it's so cool that they're now also working on getting this in dialogues and other types of elements. So with something called the invoke attributes, they will make more buttons do stuff without JavaScript. It's just kind of cool. There are other attributes you can use like popover target action, where you can say this button can only show something or it can only hide something. And there are different types of popovers. The auto one will close other popovers and it's going to like dismiss, meaning when you click outside of it, it will disappear. And the manual one, which will not like dismiss and will not close others, and usually will open that when it's correct. You can also open them in JavaScript. So you can do element.showPopover. Again, you'll need the reference to the actual element in the dom for that.

Now popover is supported as mentioned in all the browsers. In Firefox, it's behind the flag. In other browsers, it's available. Your users might not be using the latest version of Safari, for instance, but it's coming. And I think that's cool. It's time to experiment with it. Now when I was working on popover and joining these open UI meetings, we kept talking about popovers and dialogues. And I realized that I didn't actually understand it as well as I thought I did, because I kept hearing all these phrases like, this is modal, this is not modal, this is this, this is that. So I started to think about how are these things actually different? And I want to share what I found. There are a couple of different axes on which they are different. So the first one being modal versus non-modal. So modal is a bit of content that is the only thing you can interact with. So if you are tracking your users according to EU law, you need to get permission. And if you don't have the permission, they can't interact with the site.

So it's a good use case. It's a bit annoying thing to have, but it's a good use case for like blocking access from the rest of the page. Another example is when you're on a Dutch government website and your session time's out, that's after 50 minutes, you usually show a modal to ask people to extend their session. Because if they are midway their text return, that takes two hours and they press submit, they might not be able to submit it if they're no longer authenticated. So these kinds of things are typical kind of modal examples. You need to interrupt the user. It's a bit like an alarm clock in the morning. You need to interrupt the person even if they might not like it, because reasons. Another example is a game over screen. You're playing a game. You can no longer play the game because you're dead. You can't go back to the game, you can only kind of interact with this game over screen. It's the only thing available to you.

Now, non-modal is the opposite of that. So it's a thing that opens on top of other contents, but also you can still interact with everything else on the page. So it's more of a part of the rest of the content. So it's things like toggle tips and menus and chatbots as well. Imagine a chatbot where you could only chat and not look at the rest of the site. So making something modal is a drastic measure. You probably don't want to do it with many things, but sometimes you kind of have to.

Now, another axis is light dismiss versus explicit dismiss. Basically, the difference is that with explicit dismiss, you will press a button to dismiss the dialogue, whereas with light dismiss, it kind of disappears automatically. So when you're choosing a font in Google Docs and you scroll or like click outside, that's just going to disappear. And that's fine. Like you don't expect it to stay there forever, it will just go away. So it's that kind of UI that needs a light dismiss.

Then Z-index versus top layer. With Z-index in CSS, you can change the order of things. Like sometimes you have multiple things in the same place. And with Z-index you can kind of change the ordering and say, this is going to be on top and that's not. Top layer is quite different because it's a layer that's on top of everything. So even your highest Z-index, if you have like a 9,999, top layer's still going to be on top of that. It's a separate thing. And that's also how it renders in like Chromium browsers, and will show us a thing that's kind of next to the HTML element. So it's really like its own world. And the way layering works there is not through Z-index, but through the order in which things are added to the top layer. So to get this second thing to be on top of the first thing, you need to edit seconds, basically, or take everything out if you want to re-order stuff.

Then backdrops. Some of these patterns also have backdrops. They can be in modal and non-modal things, but usually they are part of modal dialogues. So sometimes they have backdrops, and if they're in the top layer, they have a built-in styleable backdrop. So with colon colon backdrop you can style through CSS, power of CSS, awesome, style your backdrop to be any color you like, have a blurry effect, all these kinds of things. And then there's keyboard focus traps that sometimes need to happen in modal elements, it's usually used and sometimes in non-modal things as well, like calendars, where you really don't want users to escape the thing, because it might be annoying for them to lose track of where they were.

So focus traps are sometimes useful, but always temporarily. So these are the things, kind of how they are different, and I wanna show you kind of how to interact with popover and the dialogue.

So modal is what you get when you use dialogue with that show modal method, that's the only way to get the browser to do something modal for you. Then non-modal is what you get with anything else. So modal, a dialogue with show method, or popovers, they will be non-modal. Then light dismiss, you can only get when you popover equals auto. And explicit dismiss is what you get with popover equals manual, or with any kind of dialogue that you're building. Then ZnX, you always get ZnX, you get top layer access when you use popover or dialogue with show modal. There is no other way to get into the top layer. Well, full screen API is one if you're using that. But popover and dialogue with show modal are the only ways to get this. So no library is going to provide this for you without using these primitives. Because this is the only way that browsers are gonna let you into that special top layer. Now, ZnX is what you get when you use dialogues with show, or any kind of content that you're building. Backdrops then, they are built into any top layer element. So, same as before, it's popover and it's dialogue with show modal. And then, a keyboard focus trap is what you get when you use dialogue with show modal. So the browser is going to take care of it for you. Seems kind of exciting. Now I wanna quickly dive into semantics for this. Because that's a really important part of making accessible dialogues on popover. You need to know what stuff is. Now, I studied philosophy, so for me, semantics would be like, what is this thing? But if you talk about web developers, it's probably what is this thing in this page or app? That's kind of what the science of semantics is all about. And you'll have semantics in your site, like when you use headings, you get heading semantics. And they are very helpful because a screen reader user can pull up a list of headings and then browse by headings. Actually, one of the most common ways that people with screen readers navigate across websites. So they'll look at your headings. So provides an API, basically, of headings. An anchor tag comes with the link, a list item comes with list item, dialogue comes with dialogue. Divs come with nothing, which is fine in some cases, if there's nothing to convey.

You can also add roles to divs and you can add as mentioned that popover attributes. And the thing to note here is that popover attribute is not gonna add any semantics for you. So like a heading tag will give you a heading semantics, popover will give you nothing. It's going to add behavior and not semantics.

And so in the next few slides, I'll show you a couple of different semantics that you can add yourself. So if you have a div with popover element on their attributes, you can then add a role attribute to decide what role this is going to be within the page. The most common one is dialogue. So you can have popovers that are dialogues. They're very common. Like I said before, they are smaller windows, sub windows, and it's basically the case when you have like multiple things in there, interactive elements, maybe some buttons, some links, that's usually a dialogue that people can interact with. Teaching UI is often a dialogue, mega navigations could be because they have lots of stuff in there. And then the next one is listbox. That's basically what you use when your popover is something that people need to choose from. So an emoji ficker or like something to check a currency, all these kinds of different things. So listboxes are also part of combo boxes, but then you're nesting stuff, right? So the listbox is the kind of thing that people pick from, and you might have other things in there as well.

Then the menu role is quite common as well. So that's what you use when you have a bunch of actions that users can do. So a menu is not for navigation. If you have a navigation thing at the top of your page, that's the navigation. A menu is really with actions in it. So it will have buttons, stuff that people can do. It executes functions basically. So in this case, there is a function to remove an item, to duplicate, it's basically like an application type of thing. It's also what is used for a menu like in Google Docs, the file menu that you open, that's typical menu as well. Then tooltips, they're quite common popover use cases. The thing to note about tooltips is that they are plain text. So when you have a string of text that goes into a tooltip, when you have anything more, it's usually a toggle tip that is more like a dialog. So if you have text in there, but also a heading and also a button to dismiss it, that's probably a dialog, even though it feels a bit like a tooltip. I don't know if we lost the connection there. That's cool.

Might come back. So in terms of semantics, the dialog element has dialog semantics, it's built in. The popover has no semantics and you need to pick it yourself.

Now, moving from semantics, I want to talk a little bit about positioning and I don't have a lot of time to cover a lot about that. But the thing to note about positioning is that both dialogs and popovers are centered by default because they are in the top layer, the browser doesn't know where to put them. So they are not going to be relative to other content on your page. They're actually going to sit in the center. So that's something to keep in mind.

If you want to anchor your popover to the thing that invoked it, then you need to think about how you can do that because only one of them is in the top layer. So your popover is in the top layer but the button that opened it is not in the top layer. They don't know about each other because they are very separate layers. So that's important to keep in mind because often you want to acquisition a popover relative to the thing that opened it because they are visually close to each other.

So, two solutions basically for popover positioning. So one is you use a library like floating UI and you calculate where the thing needs to be and you put something like cells and like put it where it can go. Or you can use anchor positioning, which is a new proposal. It isn't out yet, although it is in Chrome, but it's still kind of in development. And that is going to solve it in CSS. So rather than importing a library for positioning, this will allow you in CSS to say, make this thing anchored to that thing and kind of give you a way to automatically do that. Again, without libraries. As I don't have a lot of time to go into it, I'll refer you to my blog post called Positioning Popovers. It tells you more details about how that would work.

For now, I wanna wrap up. So we've talked about UI considerations and semantics. A couple of things that I hope you've taken away from this talk. One is that dialogue and popover APIs, they can reduce your JavaScript bundle. And that's very exciting, I think. You no longer need the library to do dialogues. A lot of stuff can be taken care of by the browser. The popover attribute also just adds behavior. It doesn't add semantics.

That's the case for a lot of things, right? There is also the TEF index attribute and the content editable attribute. They also add behavior. They don't really do anything else. It's very common for attributes, but important to note.

Then, top layer access is an important facet of this. So popovers and dialogues with showModal, they get top layer access, nothing else will. So you can't get top layer access with any other things than these APIs. And last thing to mention is, don't use popovers to cross-promote your products. That's not what it's for. And with that in mind, I want to thank you very much and refer you to my slides that are on that QR code. Thanks.

So I think there's one that was getting the most excitement from people, which is what's your opinion on popovers or modals in mobile and the mobile app space? From the points you've mentioned here, it seems like mobile apps implement them more gracefully in general. Would you tend to agree with that? Yeah, yeah, I think that's fair. Yeah, yeah, I agree with the point. Yes, great! Excellent! This next person's brought up the difficulty that popovers and modals can present for, from an accessibility perspective. What's your kind of thoughts there? Yes, it's true. But, yeah, accessibility is a very wide subject. There are a lot of different users of the web, and they also bring benefits to lots of other users. Like, there is a benefit in that they help you make your content such that some stuff is hidden and some is visible, which makes your interface more concise and will make it more usable. Now, it's super important to make sure that you do it in an accessible way. Today, people are building a lot of these components in an inaccessible way, and I hope that both popover and dialogue can actually help make it more accessible overall because the browser will take care of more of the accessibility aspects of it. So, it can build in accessibility, so to say. And that is really hard because there's a lot of nuance to it, but this is what browsers are trying to do today. So, they'll take care of relationships like, is this thing expanded or is it not expanded? Does this thing say something about that other thing? That's kind of relationships that people who use screenreaders need to know about and that often aren't put into the system. So, with these new APIs, they could be done by the browser, and I think that's really exciting because it allows us to build more stuff and the browser to do more accessibility. So, I think that's cool. Nice, and to keep that in the forefront of our minds when we're developing in place. So, after decades of deprecating visual stuff in HTML, oh, here we go. Just looking at the questions moving around. What's your opinion on introducing a visual attribute-like popover? Interesting question.

It's not just a visual. So, it introduces keyboard behavior and introduces focus management and all these kinds of things. So, yeah, I don't agree that it's a visual thing, but it's also not a semantic thing as mentioned. Like, yeah, it's just behavior basically. I guess this kind of highlights the point that you brought up at the start around there being these disparities around the importance of semantics.

Yeah, yeah, there's a lot of different semantics that this can work with, but you still need to do your own layout for popovers. So, by default, it's a div or whatever you use, and you still need to design them yourself.

Well, staying on that theme, there's a question here from Alexandra. Why did popover become an attribute instead of its own element? Which elements would it potentially be used other than? That's a really good question. It's related to these different semantics that I highlighted. So before we thought, and at that time we also thought it would be called popup, but decided not to. That was a proposal for an HTML element that would do it. But we realized that there was no one semantic that would actually cover that because there are different things. Like, some things are menus, some things are list boxes. So if you're going to give a menu default then what if it is a list box? So we decided like it should have no semantics, it's just behavior. But yeah, that was a process, because it was first imagined as maybe there should be an element. There was even talk about multiple elements. So you'd have like a list box element and a menu element. Menu already exists but deprecated, so yeah. Long story, short. It's difficult to look ahead and anticipate how we could have been using the web now.

Yeah, for sure. So I think we've got time for maybe one last question. So we've got the most updated one here by a couple of late entries, but Biomar seems to be, since it's a browser-based feature, does this mean that one day we can turn off all modals without disabling JavaScript? Yeah, that's a cool prospect, yeah. It will make that a whole lot easier, but I guess like the ad people will still work around it and annoy you. It will happen, yeah. Well, I was gonna say they... Ads will find a way not to go full Jurassic Park on it. Get a good ad-blocker, like this is very important. Excellent, on that note, thank you so much for your talk today. Thank you. Now, you...