Stacking issue with navbar and control groups

[llorca]

Bug report

• Package version(s): 1.9.0
• Browser and OS versions: Chrome 56, macOS

Actual behavior

Expected behavior

[llorca]

cc @cmslewis

[cmslewis]

Look into transform: translate3d(0, 0, 0)

[llorca]

Also look into:

• Bump z-indices range from 10 to 100 (level 1 = 0, level 2 = 100, level 3 = 200, etc...)
• (@ggray) non-integer z-indices, though spec says integers only: https://www.w3.org/TR/CSS2/visuren.html#z-index

[giladgray]

as easy as we-already-have-this-mixin

[adidahiya]

Bump z-indices range from 10 to 100 (level 1 = 0, level 2 = 100, level 3 = 200, etc...)

how does this help?

don't we just have to put the button group example and navbar in separate stacking contexts?

edit: yeah gilad has the right idea in #1015

[llorca]

Global z-indices are always safe and explicit. The bigger the range, the more elements you can play with in your stack (see control groups). I'm personally not a fan of the hacky translateZ, and I'm extremely confused with how multiple translateZ'd elements would interact with each other. But, it'll do the trick for now!

[adidahiya]

Global z-indices are always safe and explicit

I'm pretty opposed to this. I think it's a backwards step in the wrong direction. I was always confused / concerned in the bootstrap or foundation CSS world where there was a global z-index scale to follow. Why not scope stacking concerns to local components if we can?

[llorca]

Well, I'm not sure what's confusing about z-indices since it's a single unified scale across your system, really can't get easier. For instance: let's say we have that control group stack with specific z-indices; we also have a navbar that's conceptually always on top of everything, so we give it a greater z-index; now put your control group in the navbar and they will now be on top of the navbar. Done deal.

As I said previously, I'm cool with Gilad's fix, but I'd be curious to hear your take on these two things:

• the hacky translateZ solution: z-index is made for stacking/layering, and AFAIK translateZ isn't
• how do you safely control stacking for multiple translateZd elements?

[adidahiya]

Multiple translateZ elements don't get the same stacking context; they create a new one. MDN has good docs on this.

We've experienced a number of problems around the global nature of CSS in building applications which feature multiple versions of Blueprint on the same page; I don't want to add z-indices to that list of concerns.

[giladgray]

@llorca i hate to say it, but this is not a battle you want to fight.

the global-ness of z-index is its Achilles' Heel and has bitten us (and every other CSS developer) at least once. case in point: remember the first time we increased the z-index layer spacing? and now you want to do it again? when does it end?

stacking context and z-index isolation is our primary defense against the global-ness of z-index. it lets us safely use this powerful layering tool such that we're sure layers won't leak out of some scope. "layer leakage" is the root cause of this bug, and stacking context isolation is the solution to that bug.

it's important to note that transformZ is merely one way of creating a new stacking context; MDN lists twelve separate ways to do it. my initial implementation used will-change: opacity (even though the styles don't actually set opacity) and worked perfectly. (i chose opacity instead of transform because of #854, but there didn't seem to be a difference between the two in my testing.)

by the way, that MDN article linked above is the holy grail for stacking context questions. i re-read it monthly and there's been a link to it in our docs since the very early days.

[erikwiffin]

I see that this is closed, and I'm probably too late, but I'd like to put in a vote against local stacking contexts, especially in this situation. Since 1.16 was released, I've been trying to hunt down a bug where a react-select dropdown inside a control group was showing up below elements further down the page. Yes, they could attach the dropdown menu to the document body like you do with the Popover, but since creating local stacking contexts isn't standard, I don't think most libraries are likely to do that.

On the plus side, I learned about stacking contexts, so at least that's something.