bootstrap
bootstrap copied to clipboard
twbs
“Sticky” content overlaps dropdown menus
“Sticky” content (using the .sticky-top class for example) overlap dropdown menus. This doesn’t make sense, has been raised before (#28569, #28590, #28926) without any explanation, other than a shoot-down about not rearranging the z-index scale because it’s been like that for however long.
Sorry, but having “sticky” content slide over dropdown menus doesn’t make any sense, whatsoever. So what is the actual rationale for leaving it like this and not even considering fixing it?
The z-index scale is indeed designed with a particular layering system in mind. Some of this is mentioned at https://v5.getbootstrap.com/docs/5.0/layout/z-index/. And I'm including it here for context.
$zindex-dropdown: 1000 !default;
$zindex-sticky: 1020 !default;
$zindex-fixed: 1030 !default;
$zindex-modal-backdrop: 1040 !default;
$zindex-modal: 1050 !default;
$zindex-popover: 1060 !default;
$zindex-tooltip: 1070 !default;
Reiterating it here, early on for Bootstrap, we created a set of layers in which our UI operates.
-
-1through3is for in-component layering (e.g., button groups and input groups). - We chose the
1000s as a starting point to give folks plenty of room to wiggle around in before Bootstrap kicked in. - Given dropdowns are (typically) triggered by a button or link, they exist at the lowest plane. Dropdowns within the
<body>also shouldn't overlap any navigation... - ... which is why sticky and fixed are the next two layers.
- Sticky could be the same layer as fixed, but generally this supports the pattern we see of a fixed top navbar and a sticky subnav below it for longer in-page links (in sites and apps).
- Modals come next, and since a modal is designed to overtake everything and focus you entirely on that dialog, we layer those on top of everything, including the nav. By design, you cannot proceed until the modal is addressed.
- And lastly, popovers and tooltips come in above modals given they need to be able to appear in modals. A popover and tooltip that appeared before the modal did would most likely be dismissed (either on next click, or after focus/hover is shifted), so there's no need to layer it below modals.
So, which of those layers aren't right or are causing the most issues? A demo could help us look at things a bit differently, but if memory serves, to date this layering system has worked quite well overall.
@mdo So where I’ve ran into this issue is with a “sticky” sidebar content card on a page that also has dropdown menus. I’d expect the dropdown menus to be on top of any sticky content; I don’t see why sticky content should be in front of a dropdown menu a user’s triggered? It just looks… bizarre and not at all what I‘d expect.
That's more than fair, I get that issue. I think sticky content wasn't on our minds because we were look at is like sticky navigation in the form of navbars and what not. This is definitely a use case we should account for and would require a z-index update in v5. Not sure what we could do about v4 though.
@mdo Cool 🙂
I’m currently overriding the z-indexes in my own project to work around this, but wanted to raise it as it does seem to go against expectations. But I can understand it might get complicated with sticky navbars with dropdowns (where the dropdown needs a higher z-index than the sticky navbar) but then sticky content (like in the example above) that should sit underneath. Maybe the z-index hierarchy should go like this (highest to lowest):
- Dropdowns (always on top of “sticky” elements, be them navbars or content as per my example).
- Sticky navbars (so they are always above sticky content).
- Sticky content, such as the sticky sidebar content example.
I've ran in to this same issue with Dropdowns. IMO, Dropdown should be a higher z-index than both sticky and fixed. For example, I'm currently dealing with a scenario where a Dropdown inside a Navbar needs to overlay a sticky sidebar but it's hidden behind: https://codeply.com/p/w5ZxAjmjpo
Just pointing out we're at v5.1.3 now and this issue is still here and hasn't been addressed at all. Looks absolutely awful to have dropdown menus in navigation not visible because of a sticky sidebar on the page.
Just swap the dropdown and sticky z-index values around, and it's fixed. What's the hold up?
Just pointing out we're at v5.1.3 now and this issue is still here and hasn't been addressed at all. Looks absolutely awful to have dropdown menus in navigation not visible because of a sticky sidebar on the page.
Just swap the dropdown and sticky z-index values around, and it's fixed. What's the hold up?
Consider the context. We have a two year old thread with a couple of people discussing a change. No other issues reporting it. That tells me that, most likely, very few people are running into this issue. It also tells me it's low priority compared to other changes I could be putting my time and effort into.
If you really want this change, do the leg work and open a PR. Test out the various situations with how sticky helpers and fixed utilities affect not only one another, but our various components, too.
Or, wait for me to come back to this when I have time and not as many other higher priority issues and PRs :).
@mdo Cool 🙂
I’m currently overriding the z-indexes in my own project to work around this, but wanted to raise it as it does seem to go against expectations. But I can understand it might get complicated with sticky navbars with dropdowns (where the dropdown needs a higher z-index than the sticky navbar) but then sticky content (like in the example above) that should sit underneath. Maybe the z-index hierarchy should go like this (highest to lowest):
- Dropdowns (always on top of “sticky” elements, be them navbars or content as per my example).
- Sticky navbars (so they are always above sticky content).
- Sticky content, such as the sticky sidebar content example.
What do you all think about this order?
$zindex-sticky 1000;
$zindex-fixed: 1010; // <- don't know why the second item was 1020. I just changed to `10`
$zindex-offcanvas-backdrop: 1020;
$zindex-offcanvas: 1025;
$zindex-modal-backdrop: 1030;
$zindex-modal: 1035;
$zindex-popover: 1040;
$zindex-dropdown: 1050; // <- dropdown above popover and modal as well
$zindex-toast: 1060;
$zindex-tooltip: 1070; // <- tooltip above toast
My recommended change to the Bootstrap 5.1 order is only to move dropdown:
$zindex-dropdown: 1060;
This puts it above all the "background" elements (sticky, fixed, offcanvas, modal) but below all the "popup" elements (toast, popover, tooltip), which seems like the best place to me. Or rather, the dropdown is the lowest-priority popup.
The justification above for "dropdown" being a low value doesn't make much sense to me -- while it's true that the button/link are usually inside navs and should be considered "background", that's not true of the dropdown menu itself, which is what this z-index is applied to. That should always be on top of page content, even when opened from a background nav (or a sticky/offcanvas nav).
FWIW, I ran into this after making a sticky table header, which is another thing that Bootstrap doesn't support very well out of the box.
This puts it above all the "background" elements (sticky, fixed, offcanvas, modal) but below all the "popup" elements (toast, popover, tooltip)
@uecasm I'm not sure a modal is a background element, it's the same as a popover or tooltip. I think the dropdown menus should be behind modals (these should be in front of pretty much everything when they're active).
I think by just putting the sticky items at the lowest of the layers, should probably be enough to correct most issues, unless I'm wrong.
But anyway, having just read back over this thread, I'd like to apologise to @mdo as I can see my comment was particularly rude.
My argument for "modal as background" is that if there are background navs (or forms, or other content) with dropdowns open, those dropdowns should be closed when the modal opens. Meanwhile, the modal itself might contain dropdowns of its own, that should appear in front of the modal.
A dropdown (or more precisely, the menu part of it) is an ephemeral foreground element -- it's only open temporarily while you're paying attention to it, and once attention shifts somewhere else it should go away. But the menu items themselves might still have popovers or tooltips, hence those needing to be higher priority.
I think by just putting the sticky items at the lowest of the layers, should probably be enough to correct most issues
I agree with this.
I would like to express my support for bringing the dropdown-menu z-index above that of sticky-top
It does make most sense to put the sticky items at the bottom of the level, as that would resolve all of these issues. Hopefully it will be implemented in an update soon?
Same issue here. Dropdowns are generated by an interaction, they should always go over fixed and sticky elements, that often are simply part of page content
Using a sticky save button at the bottom of the vp. Drop-downs don't account for this height being used up and will gladly draw underneath it (as height gets even smaller, the drop-down switches to opening upwards and is no longer an issue).
A simple global override of $zindex-dropdown fixes it if you use a different layering strategy.
For me, I never want a type-ahead drop-down under an input to overlap...anything, really - it should stay in its form/container. I would rather CSS/bootstrap be smart enough to avoid it and switch to upwards sooner. That doesn't work for everyone, though (the OP wanted their drop-down to be above the sticky content, not avoid it). Given the complexity combined with the "fix" being setting one variable, not really sure this is impactful enough to be worth resolving.
