The following is a guest post by Agop Shirinian. Agop ran into an interesting scenario where he needed an element to be scrollable in one direction, while allowing the overflow in the other direction. You’d think that’s what overflow-x and overflow-y are for, but it’s not that simple. I’ll let Agop explain.
So you’re tasked with creating a scrollable menu with submenus that pop out when you hover over a parent menu item.
Simple!
Create a list for the menu, add some nested lists for the submenus, position the nested lists based on their parent list items, voilà!
See the Pen Scrollable menu with pop out submenus (broken) by Agop (@agop) on CodePen.
Wait, that’s not right. Oh, of course, we used overflow: auto
– perhaps if we use overflow-x: visible
, the horizontal overflow of the submenus will be visible:
See the Pen Scrollable menu with pop out submenus (broken #2) by Agop (@agop) on CodePen.
What gives? Why do we still get scrollbars?
The Problem
If we look at the W3C spec, we find the following explanation:
The computed values of ‘overflow-x’ and ‘overflow-y’ are the same as their specified values, except that some combinations with ‘visible’ are not possible: if one is specified as ‘visible’ and the other is ‘scroll’ or ‘auto’, then ‘visible’ is set to ‘auto’.
Basically, this:
overflow-x: visible;
overflow-y: auto;
Turns into this:
overflow-x: auto;
overflow-y: auto;
So we can’t have visible horizontal overflow if the vertical overflow is invisible, and vice versa.
And if we can’t have visible horizontal overflow, we can’t have our pop out submenus!
The Solution
Interestingly enough, if we omit the position: relative
from the menu items, the submenus do show up, positioned based on their closest positioned ancestor. In this case, they don’t have a positioned ancestor, so they’re positioned relative to <body>
:
See the Pen Scrollable menu with pop out submenus (step 1) by Agop (@agop) on CodePen.
Basically, in order for an absolutely positioned element to appear outside of an element with overflow: hidden
, its closest positioned ancestor must also be an ancestor of the element with overflow: hidden
.
Knowing this, we can add a wrapper around the menus to act as the closest positioned ancestor for each submenu. Then, whenever the user hovers over a menu item, we can position the submenu wrappers using a bit of JavaScript:
See the Pen Scrollable menu with pop out submenus by Agop (@agop) on CodePen.
And that’s it! Since neither the menus nor the menu items are positioned, the submenus are able to pop out of the hidden/scrollable overflow. Now we can have as many levels of nested submenus as we want, and we won’t get any undesired clipping.
Takeaway
Unfortunately, this method of showing items that would otherwise be hidden is very obscure.
It’d be nice if we could specify a clip depth, which would control which ancestor in the hiearchy would be responsible for clipping a particular element:
./* Fair warning: not real code */
.submenu {
/* only an ancestor 2 levels up can clip this element */
clip-depth: 2;
}
Or, even better, perhaps we could specify the clipping parent by a CSS selector:
/* Fair warning: not real code */
.submenu {
/* only an ancestor that matches the .panel selector can clip this element */
clip-parent: .panel;
}
Thanks for the post. I was just working on a similar problem a couple hours ago. I will try this tomorrow to work out a fix
I swear, the specs for overflow-x/y are among the most idiotic ever. What’s the unearthly reason to forbid having simple combinations like visible/auto?
Just don’t tell me it’s because it’s complicated…
It’s likely because the specificiation paves the cowpath; following the original implementation from Microsoft in IE 5. Altering the behavior would break that legacy compatibility.
Thank you for the effort, it was well-written.
The real “Takeaway” is that in 2014 we still can not use state-of-the art html/css to create menus which were state of the art in 2006.
Proceeding beyond 2006, this example does not look great on a small mobile device. I get blinky/flashy artifacts on a modern iphone for example.
I am aware of the standard excuses, no need to trot them out. However, this should not end up in a modern web app without caveats (“a desktop-preferred technique to…”). If I’m wrong, please point me to the live, production site which uses this technique.
We can’t sweep mobile under the rug in 2014, and it’s not clear how to fix your approach on a mobile device. If we can’t discuss the elephant in the room, we should at least acknowledge it :-)
thanks again!
You’re right, I wouldn’t use this technique on a mobile device.
..or anything at all without a decently large screen and a persistent cursor to hover over things ;)
This technique mainly aids desktop applications with long menus and lists with popups to reveal additional information about those items.
standard-body, I actually had to use this technique, which I stumbled upon for our internal application.
Yes this is a desktop oriented app and for mobile would not use it, mainly because mobile UI/UEX requires a different set of requirements.
Yeah position is great except when it isn’t. Couple this with visibility and you can pull your hair out in complex interactions.
Great posts. I come into this on almost every project nowadays. Mobile menu design pattern seems to have it’s quirks that need to be ironed out. I will be keeping this in mind for my next build when I undoubtedly run into this again.
Position: fixed; is also able to get outside any overflow: hidden; element since it only positions to the viewport and so also only accepts the viewport overflow.
Great post. But overflow doesn’t work well in mobile devices. Is there a solution except for using third-party plugins?
I’m not entirely sure this approach would make for a good mobile experience anyway, so you would probably want to engage in some creative progressive enhancement. With several levels of menus flying out, this seems best suited for wider screens.
Woaw, this is a good one !
For those, like me, who have to deal with IE7 every day : you know what ? It even works on IE7 ! (JSFiddle)
Thanks a lot for this trick !! :)
Speaking of coincidences! I was struggling on this exact problem yesterday for a mobile sliding navigation I was tasked to build! This works beautifully on all devices.
why the
.related-articles-title
,.comments-title
,.comments-title
havemargin-bottom: -7px
?it was blocked.
http://codepen.io/davidyarham/pen/sHiGm
Something I did a while ago, breaking out of an overflow hidden.
Almost forgot – You needn’t Wrap the Top Tier Items in the Div Wrapper either, incase you want to position them inline or otherwise :)
PURE CSS Solution!!!
Hi there,
I have achieved the same solution using pure css – no need for the JS to position the subs correctly :)
Use the following for your css – and of course play around and modify the attributes to suit your needs:
Cheers, WONDERFUL CODING!
Hey HueMan, can you share a working CodePen?
Hover is dead bro.
From John Pearse, sent to me after the comments had closed:
I see what John means about scrolling the parent menu and not seeing the child menu move along with it. The solution presented here is already a JS solution though, and so more JS could fix it (scroll event handler, reposition submenu).