TheOdinProject / curriculum

The open curriculum for learning web development
https://www.theodinproject.com/
Other
9.65k stars 13.09k forks source link

Advanced HTML and CSS: Mention a browser extension to inspect stacking contexts #28566

Open silenceinspace opened 1 month ago

silenceinspace commented 1 month ago

Checks

Describe your suggestion

Hi there. I would like to suggest mentioning a browser extension called "CSS stacking context inspector" in the Transitions lesson. It creates a new tab in devtools, which helps with:

One of the articles in the assignment section of the lesson — https://dzhavat.github.io/2021/02/18/debugging-layout-repaint-issues-triggered-by-css-transition.html — is the exact reason why I needed to see more explicitly what stacking contexts there are. Because the author says this:

What about “stacking context”? Next on the list was “stacking context”.

The MDN article explains this concept in more details but basically elements can be placed in different stacking contexts which are then stacked on top of each other. A new stacking context can be created by applying some special properties to an element. Some of those properties are position: relative, opacity value less than 1, transform, etc.

In my case, the span element contained opacity and transform. Other elements on the page with special properties were li items used for wrapping each post link. They had position: relative applied to them.

This is misleading because position: relative DOES NOT create a stacking context on its own. It does so only in combination with z-index (of value other than auto). Thus, when I was trying to understand why the bug mentioned there was appearing, I was not sure why the author's solutions worked.

But as soon as I could clearly see the stacking context hierarchy, it made things move forward. First of all, I realized that a stacking context hierarchy is not what I expected it to be when there are nested stacking contexts. What I mean...

<html>
  <div class="one"></div>
  <div>
    <ul>
      <li class="two"></li>
    <ul>
  </div>
</html>

Even though I later noticed it was mentioned in another resource from the assignment too, I was still convinced that div.one and div.two are on different levels of the existing stacking context hierarchy. But they are not. They are both nested in html.

An important distinction: we're not talking about parent/child relationships here. It doesn't matter that the tooltip is more deeply nested than the header. The browser only cares about stacking contexts.

So once I realized there are only two stacking contexts on the author's page — html and h1 span with opacity < 1 and transform — I knew the bug, where one small transition triggers repaint for almost the whole page, was not only about stacking contexts. After some extra research, I think I have grasped why the two solutions work.

  1. Removing position: relative from li elements sets their position back to the default — static. It means that h1 span's stacking context will finally work properly. Once the transition is triggered, it repaints that span without repainting any other unnecessary elements.

  2. Setting position: relative + z-index:2 on the span with a transition means that span is put upfront. So the browser engine can easily repaint it without repainting other elements "behind" since they have no changes.

Anyways, feel free to correct me if I am wrong but the bug was caused more by painting order than stacking context. It is something the author did not unfortunately touch upon. As a result, a student like myself is left wondering why the heck one transition with its own stacking context repaints later encountered in the tree elements.

Path

Node / JS

Lesson Url

https://www.theodinproject.com/lessons/node-path-advanced-html-and-css-transitions

(Optional) Discord Name

No response

(Optional) Additional Comments

No response

KevinMulhern commented 3 weeks ago

@TheOdinProject/html-css any thoughts on this one please?