It’s a reasonable UX thing that you can click-to-open something, and then not only be able to click that same thing to close it, but click outside the thing that it opened to close it. Kitty Giraudel just blogged about that. The trick is that once the thing is opened, you attach an event handler to the window
with that watches for events (like another click). If that subsequent click did not happen within the newly-opened area, close it. Like, literally thing.contains(event.target)
. It’s a nice trick, I think.
There are lots of little things to think about though. For example:
we have to stop the propagationg of the click event on the toggle itself. Otherwise, it goes up to the window click listener, and since the toggle is not contained within the menu, it would close the latter as soon as we try to open it.
Right right. Can’t have that or it breaks the whole thing.
We have this same pattern in a lot of places on CodePen. Like Kitty, we have it implemented in React. In taking a peek at our implementation, it’s got a number of bells-and-whistles I figured were worth mentioning. For example, ours isn’t a function or hook, but a component wrapper we use like:
<ClickOutsideDetector
listen
onClickOutside={() => { closeTheThing(); }}
>
A Menu or Modal or something.
</ClickOutsideDetector>
That way it is a generic wrapper that we can use for anything on a “click outside”. The bells-and-whistles being:
- You can pass in
component
prop so that it doesn’t have to manifest as a<div>
but whatever you want it to be semantically. - The
listen
prop allows you to toggle if it is currently actively listening to events. Like a quick way to short-circuit it. - An ESC keypress is the functional equivalent to clicking outside.
- Handles touch events as well as clicks
- Handles a case where the click outside happens into an
<iframe>
in which case thewindow
has ablur
event rather than a click. - Allows you to pass in elements to ignore, so rather than the
stopPropagation
trick that Kitty documented, we can be specific about elements that don’t trigger a click outside.
So many little things! To me this is the kinda perfect little example of real-world development. You just want one little behavior and ultimately there are a ton of considerations and edge cases you have to deal with and it’s never really done. I just touched our component in the last few months because of a third-party tool we used changed how they did something which affected iframes in use on the page. Ultimately I had to watch for a blur
event that then check the classList
of document.activeElement
to see if that was the thing eating the click outside!
Annnnyway, I tossed up a only-slightly-dumbed-down version of ours here.
And I saw something from Kitty’s post that we weren’t handling, and it’s in the very first sentence:
we needed a way to close the menu when clicking outside of it or tabbing out of it.
Emphasis mine. Don’t worry, I’ve got a TODO in our code for that now.
If you want a no-JS solution, you can just put tabindex=“-1” on the body.
I’m not following.
A simpler solution is to close the thing in a div which covers 100vh and vw respectively, therefore when either click the thing or the div the toggling effect takes place.
Exactly what a responsive hamburger menu is supposed to do: click on the small hamburger icon and your mobile website is becoming covered by a transparent or whatever solid colored background, which has inside it fully centered the nav-ed links (with
display: flex
plusjustify-content: center; align-items: center;
placed in the style of that div). Of course the div is initiallydisplay: none;
aka hidden.Meantime, the thing (which could be for example a link inside that nav block) could have
onclick='this.style.display="none"'
preceded of course by the action it is supposed to do (open a new tab, etc) if you simply want it to disappear, or even better,onclick='this.parentNode.parentNode.style.display="none"'
for the case that the hidding effect is needed to jump 2 levels up, as to make the div to disappear (because the parent of the parent of the link is the parent of nav element).Imho we have here a too old problem already solved by the responsive design usual coding practice so no need to reinvent the wheel or to pretend that a new solution would even be necessary.
Why not use the onblur event?
I’m not following.
Could this be a CSS-only solution? (ESC keypress not working!)
A combination of grid, z-index, a couple of pseudo-elements, focus and focus-within.
A combination of adding tabindex: -1, and a foucusout event listener on the modal achieved the same result in a lot fewer steps. Am I missing something?