On writing-up an answer for a different question on SO, I made this snippet:
#import url('https://fonts.googleapis.com/css?family=Shadows+Into+Light');
/* relevant CSS */
div {
position: relative;
}
div::before {
content: '';
position: absolute;
top: 0; left:0;
}
div>span {
position:relative;
z-index:0;
}
/* rest is just styling - should be irrelevant for the question */
div {
font: normal normal normal 2rem/1 'Shadows Into Light', cursive;
color: white;
text-align:center;
margin: 1rem;
padding: 1rem;
min-width: 15rem;
cursor: pointer;
}
div::before {
width: 100%;
height: 100%;
opacity: 1;
transition: opacity .3s cubic-bezier(.4,0,.2,1);
background-color: #bada55;
border-radius: .4rem;
}
div[orange]:before {
background-color: #f50;
}
div:hover::before {
opacity:.65;
}
body {
margin: 0; padding: 0;
}
center-me-please {
display: flex;
flex-direction: column;
align-items: center;
justify-content: center;
min-height: 100vh;
background: transparent url(http://lorempixel.com/g/1200/800/fashion) no-repeat 50% 50% /cover;
}
<center-me-please>
<div><span>#bada55</span></div>
<div orange>not so #bada55</div>
I was surprised to notice the ::before element is rendered above textnodes (orange element) and, in order to prevent it from happening. I had to wrap the textnode in a span element and give it a non-negative z-index and a non-static position (#bada55 element).
On inspection, while the ::before element has a default (expected) value of z-index (auto), the textnode doesn't seem to have one at all (or at least Chrome's not able to show it).
Up to now I liked to think of myself as a z-index little ninja, idea partly backed-up by developing this toy to help friends and colleagues better understand stacking contexts principle and z-index in general.
As you might have guessed, I'm looking for any explanation on why ::before is not rendered below everything else in an element by default (it's first, therefore below, right?) and for any evidence about this being either a (known?) bug or intended (by design?) behavior.
A spec I might have missed or misinterpreted would be great.
::before is painted below text content by default — and the default case is when everything is non-positioned.
But your ::before is absolutely positioned. Positioned boxes are always painted in front of non-positioned boxes. Refer to section 9.9.1 (emphases mine):
Within each stacking context, the following layers are painted in back-to-front order:
the background and borders of the element forming the stacking context.
the child stacking contexts with negative stack levels (most negative first).
the in-flow, non-inline-level, non-positioned descendants.
the non-positioned floats.
the in-flow, inline-level, non-positioned descendants, including inline tables and inline blocks.
the child stacking contexts with stack level 0 and the positioned descendants with stack level 0.
the child stacking contexts with positive stack levels (least positive first).
Wrapping your text content in a positioned span causes it to be painted in front of the ::before content as expected since then you have two positioned boxes in source order.
Related
Here's an example of a CSS tooltip. The author positions the toolip relatively.
.tooltip{
display: inline;
position: relative;
}
However, the tutorial says,
Relative. This type of positioning is probably the most confusing and
misused. What it really means is "relative to itself". If you set
position: relative; on an element but no other positioning attributes
(top, left, bottom or right), it will no effect on it's positioning at
all, it will be exactly as it would be if you left it as position:
static; But if you DO give it some other positioning attribute, say,
top: 10px;, it will shift it's position 10 pixels DOWN from where it
would NORMALLY be. I'm sure you can imagine, the ability to shift an
element around based on it's regular position is pretty useful. I find
myself using this to line up form elements many times that have a
tendency to not want to line up how I want them to.
There are two
other things that happen when you set position: relative; on an
element that you should be aware of. One is that it introduces the
ability to use z-index on that element, which doesn't really work with
statically positioned elements. Even if you don't set a z-index value,
this element will now appear on top of any other statically positioned
element. You can't fight it by setting a higher z-index value on a
statically positioned element. The other thing that happens is it
limits the scope of absolutely positioned child elements. Any element
that is a child of the relatively positioned element can be absolutely
positioned within that block. This brings up some powerful
opportunities which I talk about here.
What I understand is that, without modifiers like top, left etc. relative is equivalent to static and goes with the flow of the page. Then how's the tooltip being displayed at the correct position, i.e. above the hyperlink? Shouldn't it appear at the end of the page instead?
The CSS you provided for tooltip is not complete. I think you saw it in w3schools. But note that there are two elements for it: a parent element with .tooltip class and a child element (actual tooltip text) inside it with .tooltiptext class.
the parent element has position: relative without any top, left ... positions which acts as you said as a static element in its original (normal) place. But the child tooltiptext inside it has a position: absolute which is why it is seperated from normal text flow and put over them.
Here is a sample:
.tooltip {
/* this is just to add meaning for position:absolute of .tooltiptext */
position: relative;
color: navy;
}
.tooltip .tooltiptext {
/* Position the tooltip */
position: absolute;
z-index: 1;
top: 100%;
left: 10%;
/* style the tooltip */
min-width: 50px;
background-color: #ff9;
color: black;
font-size: 10pt;
border-radius: 3px;
padding: 3px 10px 6px;
white-space: nowrap;
visibility: hidden;
}
.tooltip:hover .tooltiptext {
visibility: visible;
}
<span>Sample: </span>
<span class="tooltip">Hover over me
<span class="tooltiptext">Tooltip text</span>
</span>
So, I've managed to make this CSS work, but I'm not 100% sure why it does. I know that's the classic programmer's scenario. I'd like to know why it does, though, so that I can get better.
Here are the two JSfiddle cases (they're exactly the same but with one line different):
With display:block
With float:left
As you can see, the important line of CSS:
.name::before {
content: '';
background: purple;
position: relative;
float: left; /* OR -display: block;- */
height: 22px; width: 100%;
margin-top: -22px; margin-left: -11px;
padding: 0 0px 0 22px;
}
With display:block, the pseudo-element matches the width of the main element (including the borders and padding. However, with float:left, the pseudo-element actually extends the width of the main element; if you change the padding-left to 11px, the increased width disappears, but the ::before stops short and doesn't include the main element's padding+border. This makes me think that inline elements affect other elements that it doesn't share a line with, as long as they're in the same container. Is that right?
Oddly, if you make change the padding to padding: 0 11px, it doesn't extend the right side of the ::before to the edge of the main element like I thought it would. Why is that?
Thanks!
My opinion is:
display: block;
only display the element in block,
while
float: left;
does push the element to the very left of its parents.
If you want to have all the elements to be in one line,
try to use display: inline;
I'm trying to override / ignore the stacking context for an element so it can be positioned on the z-axis relative to the page root.
However, according to the article What No One Told You About Z-Index:
If an element is contained in a stacking context at the bottom of the stacking order, there is no way to get it to appear in front of another element in a different stacking context that is higher in the stacking order, even with a z-index of a billion!
New stacking contexts can be formed on an element in one of three ways:
When an element is the root element of a document (the element)
When an element has a position value other than static and a z-index value other than auto
When an element has an opacity value less than 1
With the following example:
.red, .green, .blue { position: absolute; }
.red { background: red; }
.green { background: green; }
.blue { background: blue; }
<div><span class="red">Red</span></div>
<div><span class="green">Green</span></div>
<div><span class="blue">Blue</span></div>
If the first div is given opacity:.99;, (which creates a new stacking context on the first node) then even if .red has z-index:1, it will still be placed behind the other elements because it is just rendered as the highest element within that stack.
Working Demo in jsFiddle
Which looks like this:
Q: Is there a way for an element to ignore the stack context of any of it's parent elements and ask to be positioned relative to the original stack context of the page?
Q: Is there a way for an element to ignore the stack context of any of it's parent elements and ask to be positioned relative to the original stack context of the page?
No, it's not possible to transfer a positioned element between stacking contexts without repositioning the element in the DOM. You cannot even move an element to the root stacking context by using position: fixed or position: absolute (as you have observed, .red is being positioned relative to its parent, div:first-child because it creates a new stacking context).
That being said, given your HTML and CSS it should be trivial to just reassign the classes to the div elements instead, as shown in other answers and here so all your divs and spans participate in the root stacking context:
<div class="red"><span>Red</span></div>
<div class="green"><span>Green</span></div>
<div class="blue"><span>Blue</span></div>
But your situation probably isn't as simple as it seems.
We can do it using 3D transformation and we will be able to bring any element to the front even if it's trapped inside a stacking context:
.red,
.green,
.blue {
position: absolute;
width: 100px;
color: white;
line-height: 100px;
text-align: center;
}
body,
div:first-child {
transform-style: preserve-3d; /* this is important for the trick to work */
}
.red {
top: 20px;
left: 20px;
background: red;
/*z-index: 1; we no more need this */
transform:translateZ(1px); /* this will do the trick */
}
.green {
top: 60px;
left: 60px;
background: green;
}
.blue {
top: 100px;
left: 100px;
background: blue;
}
<div><span class="red">Red</span></div>
<div><span class="green">Green</span></div>
<div><span class="blue">Blue</span></div>
More details and examples here: Why can't an element with a z-index value cover its child?
As it stated in the The stacking context: "Using z-index, the rendering order of certain elements is influenced by their z-index value. This occurs because these elements have special properties which cause them to form a stacking context.
To partly overcome stacking content problem you can use css properties to display unwanted elements:
opacity: 0.1;
or
display: none;
Why in IE8, is the background color of a pesudo element flowing behind children of the parent? The text flows in front, but the background-color does not. Z-index did not seem to help any.
I haven't been able to determine if this is a bug in IE8 or not. It seems like this would have been a pretty common use-case, but I couldn't find many blog posts or SO questions related to it.
http://jsfiddle.net/VAg2E/
<div id="parent">
<img src="http://placehold.it/200x200">
</div>
#parent{ padding: 20px; }
#parent:before{
content: 'Behind the image';
position: absolute;
top: 0;
left: 0;
width: 100px;
height: 100px;
background-color: red;
}
Edit : A related Stack Overflow Question about Stacking Order
This is definitely a bug in IE8; since your :before pseudo-element is positioned, it should create a new stacking context and always be drawn on top of the img unless you give it a negative z-index (even then, the entire element should be drawn behind it, not just its background).
This issue also seems specific to stacking between :before and :after pseudo-elements and replaced elements like img. It looks like IE8 is treating replaced content differently in terms of stacking, but whatever it is doing, it's definitely not conforming to the spec.
As you're probably aware, this is fixed in IE9.
Have your exact same issue, the only thing you can do is force the stacking order via CSS and z-index. The only catch is that z-index is placed on child element starting from parent element, so you wont be able to do a proper logic order as #parent-element {z-index: 2} and #child-element {z-index: 1}, the z-index for the #child-element will just be set to level 1 as a separate stack order inside the #parent-element.
You can still set z-index for the #child-element with a -1 value, it will just get back the whole #parent-element stacking order.
So to recap:
#parent-element { z-index: 99;} /* or any arbitrary number fitting */
#child-element {z-index: -1;}
Also remember to give both elements a position: relative/absolute to enable the stacking order fo z-index
IE8 only supports pseudos if <!DOCTYPE> is declared. Source
#parent { padding: 20px; z-index: 2; }
#parent:before {
content: 'Behind the image';
position: absolute;
top: 0;
left: 0;
width: 100px;
height: 100px;
background-color: red;
z-index: -1;
}
This question already has answers here:
Why can't an element with a z-index value cover its child?
(5 answers)
Closed 1 year ago.
It seems that with markup like http://jsfiddle.net/nwekR/
<div id="container">
Outer Div
<div id="inner">Inner Div</div>
</div>
and CSS like
#container {
position: relative;
z-index: 6;
}
#inner {
position: absolute;
z-index: 4;
}
#inner is still above #container can I have #inner below?
No.
The CSS 2.1 spec states this standard of painting elements:
the background and borders of the
element forming the stacking
context.
the child stacking contexts with
negative stack levels (most negative
first).
the in-flow, non-inline-level,
non-positioned descendants.
the floating descendants.
the in-flow, inline-level,
non-positioned descendants,
including inline tables and inline
blocks.
the child stacking contexts with
stack level 0, and the positioned
descendants with 'z-index: auto'.
the child stacking contexts with
positive stack levels (least
positive first).
Given these rules and your HTML, #container is creating the stacking context for the element #inner, which means #container has to be rendered first.
Other people have already posted alternative HTML/CSS to get the effect you desired, but if you want to know more about why what you want isn't possible, here is the documentation:
http://www.w3.org/TR/CSS21/visuren.html#layers
You just need to put it outside of inner element when it comes to HTML.
Here's your solution: http://jsfiddle.net/nwekR/23/
<div id="container">
Outer Div
</div>
<div id="inner">Inner Div</div>
#container {
background: yellow;
position: relative;
height: 100px;
-moz-box-shadow: 0 2px 6px rgba(0,0,0,0.6);
-webkit-box-shadow: 0 2px 6px rgba(0,0,0,0.6);
box-shadow: 0 2px 6px rgba(0,0,0,0.6);
z-index: 6;
}
#inner {
background: orange;
position: absolute;
z-index: 4;
width: 100px;
height: 50px;
top: 180px;
right: 0;
padding-top: 20px;
}
The cleanest solution is to add an extra wrapper element, and to move #inner outside #container.
The extra wrapper element is given position: relative, so everything else should be the same as it was before, with the exception that #inner is underneath #container.
Live Demo
It is not possible(in it's current state of having inner a child of container) because when the browser renders the DOM, it goes from top down on the DOM tree, and there is no way to draw under something that has already been drawn(i.e. drawing the parent before child).
You can read more about the z-index here.
There are ways of accomplishing(by changing the html around) this however, you can see thirtydot's solution.