Why the content is not covered by the background of an overlapping element?

Here is the situation:

body {
  margin: 0;
  background: pink;
  color: #fff;
}

.box {
  margin-top: 20px;
  background: red;
}

.bottom {
  text-align: right;
  background: green;
  animation: animate 2s infinite alternate linear;
}

@keyframes animate {
  from {
    margin-top: 10px;
  }
  to {
    margin-top: -40px;
  }
}

<div class="box">
  some content
</div>
<div class="bottom">
  other content
</div>

What's happening?

As you may see we have two div without any complex styling (simply background-color). I am making the second div to overlap the first one by applying a negative margin-top. I am expecting to see one completely overlapping the other but this is not the case. The second div is sliding between the content and the background of the first one and it's a strange behavior for me.

The animation has nothing to do here, I simply use it to better show the behavior. We can simply add negative margin without animation and we will have the same thing:

body {
  margin: 0;
  background: pink;
  color: #fff;
}

.box {
  margin-top: 20px;
  background: red;
}

.bottom {
  margin-top:-10px;
  text-align: right;
  background: green;
}

<div class="box">
  some content
</div>
<div class="bottom">
  other content
</div>

So my question is : why such behavior?

By the way, we all know that there is some tricky things with CSS that we don't suspect when we face them the first time (like margin-collapsing, background propagation from body to html, white space issue,etc...) but they are clearly explained somewhere and I hope to find an official resource where I can clearly understand this and not only get something like "Maybe this happen because...", "I suspect this related to...", "I think it have something to do with...",etc.

My opinion/explanation about this

I suppose content like text are more important than background and other visual styling so maybe when we have overlapping we place all the text at the top and all the other styling at the bottom, we decide about the order inside each group and then we print the result.

Here is a more complex example:

body {
  margin: 0;
  background: pink;
  color: #fff;
}

div {
  font-size: 39px;
  line-height: 28px;
  margin-bottom: -20px;
  font-weight: bold;
}

body :nth-child(1) {
  background: red;
  border:3px solid brown;
}

body :nth-child(2) {
  background: blue;
  border:3px solid yellow;
  color: #000;
}

body :nth-child(3) {
  background: green;
  border:3px solid orange;
}

<div>
  some content
</div>
<div>
  other content
</div>
<div>
  more content
</div>

We can clearly see that the visual stack is as follow (starting from bottom to top):

Styling of the first div(background + border)
Styling of the second div(background + border)
Styling of the third div(background + border)
text content of the first div
text content of the second div
text content of the third div

Important notice: Before answering, please note that I am not looking for a fix to this or how to avoid this. By simply adding position:relative the behavior disappear and we can play with z-index to decide about stacking. Am looking to understand why such thing happen.

Solution 1:

WARNING: Reading the following information can affect your mental health.

The painting order for the descendants of an element generating a stacking context (see the z-index property) is:

If the element is a root element:

background color of element over the entire canvas.

background image of element, over the entire canvas, anchored at the origin that would be used if it was painted for the root element.

If the element is

a block, list-item, or other block equivalent:

background color of element unless it is the root element.

background image of element unless it is the root element.

column rule of the element.

border of element.

Otherwise, if the element is a block-level table:

table backgrounds (color then image) unless it is the root element.

column group backgrounds (color then image).

column backgrounds (color then image).

row group backgrounds (color then image).

row backgrounds (color then image).

cell backgrounds (color then image).

cell column rule for multi-column.

all table borders (in tree order for separated borders).

Stacking contexts formed by positioned descendants with negative z-indices (excluding 0) in z-index order (most negative first) then tree order.

For all its in-flow, non-positioned, block-level descendants in tree order:

If the element is a block, list-item, or other block equivalent:

background color of element.

background image of element.

column rule of the element.

border of element.

Otherwise, the element is a table:

table backgrounds (color then image).

column group backgrounds (color then image).

column backgrounds (color then image).

row group backgrounds (color then image).

row backgrounds (color then image).

cell backgrounds (color then image).

cell column rule (multi-column).

all table borders (in tree order for separated borders).

All non-positioned floating descendants, in tree order. For each one of these, treat the element as if it created a new stacking context, but any positioned descendants and descendants which actually create a new stacking context are considered part of the parent stacking context, not this new one.

If the element is an inline element that generates a stacking context, then:

For each line box that the element is in:

Jump to 7.2.1 for the box(es) of the element in that line box (in tree order).

Otherwise: first for the element, then for all its in-flow, non-positioned, block-level descendants in tree order:

If the element is a block-level replaced element, then: the replaced content, atomically.

Otherwise, for each line box of that element:

For each box that is a child of that element, in that line box, in tree order:

background color of element.

background image of element.

column rule of the element.

border of element.

For inline elements:

For all the elements in-flow, non-positioned, inline-level children that are in this line box, and all runs of text inside the element that is on this line box, in tree order:

If this is a run of text, then:

any underlining affecting the text of the element, in tree order of the elements applying the underlining (such that the deepest element’s underlining, if any, is painted topmost and the root element’s underlining, if any, is drawn bottommost).

any overlining affecting the text of the element, in tree order of the elements applying the overlining (such that the deepest element’s overlining, if any, is painted topmost and the root element’s overlining, if any, is drawn bottommost).

the text

any line-through affecting the text of the element, in tree order of the elements applying the line-through (such that the deepest element’s line-through, if any, is painted topmost and the root element’s line-through, if any, is drawn bottommost).

Otherwise, jump to 7.2.1 for that element

For inline-block and inline-table elements:

For each one of these, treat the element as if it created a new stacking context, but any positioned descendants and descendants which actually create a new stacking context are considered part of the parent stacking context, not this new one.

For inline-level replaced elements:

the replaced content, atomically.

Optionally, the outline of the element (see 10 below).

Note, some of the boxes may have been generated by line splitting or the Unicode bidirectional algorithm.

Optionally, if the element is block-level, the outline of the element (see 10 below).

All positioned, opacity or transform descendants, in tree order that fall into the following categories:

All positioned descendants with 'z-index: auto' or 'z-index: 0', in tree order. For those with 'z-index: auto', treat the element as if it created a new stacking context, but any positioned descendants and descendants which actually create a new stacking context should be considered part of the parent stacking context, not this new one. For those with 'z-index: 0' treat the stacking context generated atomically.

All opacity descendants with opacity less than 1, in tree order, create a stacking context generated atomically.

All transform descendants with transform other than none, in tree order, create a stacking context generated atomically.

Stacking contexts formed by positioned descendants with z-indices greater than or equal to 1 in z-index order (smallest first) then tree order.

Now seriously, refer to the w3c paint order documentation

In point 4.1, the background of children is painted

In point 4.4, the border of children is painted.

When point 4 is finished, all background and border of your snippet have been painted

Now, in point 7.2.1.5.1.1.3, the text of the children is painted.

This is the behaviour that you are seeing.

Notice also that is easy to change this behaviour. We can activate point 8.2, (setting opacity) and it will paint like you may have expected:

body {
  margin: 0;
  background: pink;
  color: #fff;
}

.box {
  margin-top: 20px;
  background: red;
}

.bottom {
  text-align: right;
  background: green;
  animation: animate 2s infinite alternate linear;
  opacity: 0.9999;
}

@keyframes animate {
  from {
    margin-top: 10px;
  }
  to {
    margin-top: -40px;
  }
}

<div class="box">
  some content
</div>
<div class="bottom">
  other content
</div>

Another snippet, showing several point in the document:

Notice that all the border and background in step 4 are rendered after step 3, and before setp 5. But the text in step 4 is step 7, so is rendered after text in step 5

div {
  width: 200px;
  height: 100px;
  border: solid 10px;
  font-size: 40px;
}

.step3 {
  border-color: red;
  background-color: lightpink;
  z-index: -1;
  position: relative;
  margin-left: 10px;
}

.step41 {
  border-color: brown;
  background-color: yellow;
  margin-left: 30px;
  margin-top: -40px;
}

.step42 {
  border-color: blue;
  background-color: lightblue;
  margin-left: 50px;
  margin-top: -40px;
  color: red;
}

.step43 {
  border-color: green;
  background-color: lightgreen;
  margin-left: 160px;
  margin-top: -150px;
  color: crimson;
}

.step5 {
  float: left;
  background-color: white;
  margin-top: -30px;
}

div:hover {
  position: relative;
}

<div class="step3">Step 3 negative zindex</div>
<div class="step41">step4 In flow, number 1</div>
<div class="step42">In flow, number 2</div>
<div class="step43">In flow, number 3</div>
<div class="step5">step 5 float</div>

I don't know if this counts as an use case : this more natural the initial behaviour the the one set by the elements positioning relative

div {
  width: 100px;
  height: 1.3em;
  border: solid 12px tomato;
  font-size: 18px;
}

div:hover {
  position: relative;
}

<div>a long stretch of text overflowing to the other div</div>
<div></div>

Solution 2:

The answer to the question is nowhere near everyone is digging. Because we all have fixed our mind at believing that this is something that leverages user experience anyhow, something intuitive. Have anyone thought this can be for any CPU processing benifit?

Browser rendering engine does not paint an element completely, and then goes on painting the next, because we have GPU technology. The rendering engine paints elements in different stacked layers one over another which are handed over to the GPU who then rasterizes all the layers into a composite layer that shows up on screen.

Browser rendered layers

So, how the layers are created?

Rendering engine paints all backgrounds and borders on the base layer.
Creates a new layer for an element who has positioning specified. The layer is stacked over the base layer for the GPU to rasterize it. When the element moves the rendering engine only tells the GPU to move the layer, GPU does the rest. CPU is saved from painting overhead.
Creates a new layer for an element who has opacity specified. When opacity changes GPU does the rasterizing work.
Similarly creates a new layer for inputs, buttons, canvases, videos everything that can cause CPU to paint repeatedly, is transfered to the GPU as a new layer. We are saving a lot CPU processing, right? :)
Denies creating any new layer for an element with negative margin :( . This is obvious browser cannot issue new layer for every element with margin, there are a lot of them. Even if it has negative margin it may or may not overlap other element. The only way to be sure is to look into the render tree. What's the point? We are trying to save processing, looking into render tree for every element will ruin it.
Issues a new layer for text element. GPU can rasterize text far more efficiently onto a background, so why paint it with CPU on the base layer?? This was the original question. I think everyone can answer it now.

Why text is painted on a separate layer above base layer?

CPU does not need to paint the text over background, CPU is happy.
When text color or shadows change CPU only paints the text layer, GPU rasterizes it on the background.
When the background changes CPU only paints the background layer, GPU rasterizes text over it.
When text is scrolled over a fixed background, no painting is needed, CPU only tells GPU to move the text layer, GPU does the rest.
And a lot more...

Now let's look into the magics we are encountering due to this.

painting and rasterizing

Case 1: When position relative is added to 2nd div it gets a new layer, this new layer is stacked over the base layer and even over the text layer of first div.
Case 2: Same thing happens when opacity is applied.
Case 3: Any transform style will create a new layer.
Case 4: This one is interesting. The margin does not create any layer for the second div, it is painted on the base div after the first div is painted, so it is painted over the first div on the same layer. The text on the first div is on it's own layer that is stacked over the base layer so GPU rasterizes the text over the background of second div.

[source: developers.google.com]

Solution 3:

This is because of hierarchy... I will try to explain it a little bit more...

body {
  margin: 0;
  background: pink;
  color: #fff;
}

.box {
  margin-top: 20px;
  background: red;
}

.bottom {
  margin-top:-10px;
  text-align: right;
  background: green;
}

<div class="box">
  some content
</div>
<div class="bottom">
  other content
</div>

Like at this your example, our hierarchy looks like:

.box
    .box content
.bottom
    .bottom content

So, right now if you don't pass position: relative for example, then it will use normal hierarchy of HTML without checking divs...

You have background implemented at .box and .bottom, so at this case when you add margin-top into .bottom, then:

.bottom and .box has same horizontal hierarchy position, but .bottom has bigger vertical, so will overlap .box background
.bottom content and .box content has bigger position than .bottom and .box so will overlap each of them
.bottom content will overlap .box content because of bigger vertical hierarchy

Solution 4:

One way to ask the question would be: could it be handled differently and still manage the different features required by CSS, especially the float property?

What the spec says is that for a stacking context (basically the top block of a part of the DOM tree that is positioned), you paint the elements in that order:

background of the top element of the stacking context
elements with z-index negative

Until now it makes sense, then you have

all backgrounds and border of all the block level elements (basically elements that are display: block but not positioned) in the tree under the top element.
then all floated elements of all the tree under the top element.
This steps in an else from step 2 so it doesn't really interfere with this specific case.
Then all in-flow elements (or non floating elements) of all the tree under top element (it's not just the texts that are rendered in 7, it's all inline elements. If your inline elements has a background, it'll mask what's behind).

The "problem" with this is that is that the in-flow elements are not rendered in the order of the tree. The background of an element lower in the tree can be rendered before an in-flow element upper in the tree. What is implied in the question is that we kind of expect something more like:

render all backgrounds and border and in-flow elements of all the block level elements in tree order.

That would generate the elements in a more intuitive way. So why then separate the in-flow elements from the rest. Why is the step 5 before step 7? It's clear that if you do it that way, then you have a problem with your floating elements. They must be placed before the rest of the flow, because that's what they are, elements that are taken out of the flow. So step 5 makes sense, you need to consider floating elements before non floating elements.

So what if they were rendered in step 4, like this:

all backgrounds and border, then floating and then non floating elements of all the block level elements in tree order.

You still have a problem, because of what is expected of floating elements. See this snippet:

body {
  margin: 0;
  background: pink;
  color: #fff;
}

.box {
  margin-top: 20px;
  background: red;
}

.bottom {
  margin-top:-10px;
  text-align: left;
  background: green;
  
}

<div class="box">
  <span>some content some content some content some content some content some content some content some content some content some content</span>
<span style="float: left; background: navy">
  floated content box<br>
  floated content box<br>
  floated content box<br>
  floated content box
  </span>
  
 
  
  
</div>
<div class="bottom">
  <span style="background-color:turquoise;">other content</span>
  <span style="float: left; background-color:bisque;">
  floated content bottom<br>
  floated content bottom<br>
  floated content bottom
  </span>
  
 
  
</div>

You'll see that the float elements don't have any impact on the height of the block elements, which is expected, else the result would be weird, not at all what's expected of a floating element. So if the floating element in the upper block was rendered before the background of the lower element then the background would be over the floating element. So rendering backgrounds, then float, then in-flow in the tree order doesn't work either. You need to place all float elements of all the tree before you get to the normal flow.

So you're pretty much stuck with this way of handling the render, meaning you have to check all your elements in one context to position floating elements, then position the rest of the normal flow. It has this strange side effect, but considering the complexity of the different positioning expected by the CSS specs, I'm not sure there's another way to do it.

EDIT:

I think this behavior is clearly specified in the specs, see here: https://www.w3.org/TR/CSS2/visuren.html#floats

The contents of floats are stacked as if floats generated new stacking contexts, except that any positioned elements and elements that actually create new stacking contexts take part in the float's parent stacking context. A float can overlap other boxes in the normal flow (e.g., when a normal flow box next to a float has negative margins). When this happens, floats are rendered in front of non-positioned in-flow blocks, but behind in-flow inlines.

Which means exactly what I've illustrated, meaning that it's expected for floating element to overlap in-flow blocks, and be rendered in front of such backgrounds.