We can create new stacking context as soon as we add z-index properties to the elements.
Only if:
the value isn't auto AND
the element also has a position value of absolute or relative OR
the element also has display: flex OR
the element also has display: grid
The relative in header doesn't seem to have a reason to exist. Once that is removed the problem goes away.
In fact you can clean it up even further.
The index: 2 in header can be removed.
The index: 1 in main can be removed, eliminating that stacking context. We have to keep position: relative in order for the circle absolute positioning to work.
The index: 99999 in circle can be removed. The div will automatically appear on top of main because of HTML source order-later/nested elements will naturally stack on top of earlier ones within the same stacking context (Stacking without the z-index property).
Now the only remaining stacking context is the one from the html root.
This demonstrates that using z-index indiscriminately can cause more problems than it solves - especially as it is responsible for a new stacking context being created on display: flex, display: grid, position: relative/absolute elements.
The article does link to the stacking context which lists the various conditions under which a new stacking context is created.
I was focusing on the ones that involved z-index in one way or another - i.e. z-index by itself isn't sufficient for creating new stacking context but it can cause one to be created when other specific declarations are already in place.
Right, which makes sense. I just thought for the sake of this article/post it's worth mentioning as some may not realise that transforms can affect the context as well.
Taking from ops example, let's say they want a fixed header and the main area to transition during route changes. Some may not expect adding a transform to main will change the stack: codepen.io/getreworked/pen/JjMrMZQ...
Creating Stacking Contexts hints at why stacking contexts exist in the first place; some property values need to be contained and isolated to keep things manageable.
Thanks for the feedback. I agree, however that was the usecase i was tackling. In essence that z-index will NOT bring the element to the top. Also added more links to the article.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Only if:
autoANDpositionvalue ofabsoluteorrelativeORdisplay: flexORdisplay: gridThe
relativeinheaderdoesn't seem to have a reason to exist. Once that is removed the problem goes away.In fact you can clean it up even further.
index: 2inheadercan be removed.index: 1inmaincan be removed, eliminating that stacking context. We have to keepposition: relativein order for thecircleabsolute positioning to work.index: 99999incirclecan be removed. Thedivwill automatically appear on top ofmainbecause of HTML source order-later/nested elements will naturally stack on top of earlier ones within the same stacking context (Stacking without the z-index property).Now the only remaining stacking context is the one from the
htmlroot.This demonstrates that using
z-indexindiscriminately can cause more problems than it solves - especially as it is responsible for a new stacking context being created ondisplay: flex,display: grid,position: relative/absoluteelements.For Firefox there is a CSS stacking context inspector add-on/extension. (Chrome devtools extension; github)
PS: Block Formatting Contexts are something entirely different.
Just wanted to mention that
transformwill also affect stacking context - which isn't mentioned in the article.The article does link to the stacking context which lists the various conditions under which a new stacking context is created.
I was focusing on the ones that involved
z-indexin one way or another - i.e.z-indexby itself isn't sufficient for creating new stacking context but it can cause one to be created when other specific declarations are already in place.Right, which makes sense. I just thought for the sake of this article/post it's worth mentioning as some may not realise that
transforms can affect the context as well.Taking from ops example, let's say they want a fixed header and the main area to transition during route changes. Some may not expect adding a
transformtomainwill change the stack: codepen.io/getreworked/pen/JjMrMZQ...Creating Stacking Contexts hints at why stacking contexts exist in the first place; some property values need to be contained and isolated to keep things manageable.
Interestingly the Incomplete List of Mistakes in the Design of CSS states that tables and
overflow: scrollshould have created their own stacking contexts as well.Thanks for the feedback. I agree, however that was the usecase i was tackling. In essence that z-index will NOT bring the element to the top. Also added more links to the article.