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:
lists what stacking contexts there are on the document;
specifies due to what properties these stacking contexts have been created;
shows a stacking context hierarchy of the whole document;
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...
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.
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.
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.
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:
This is misleading because
position: relative
DOES NOT create a stacking context on its own. It does so only in combination withz-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...
Even though I later noticed it was mentioned in another resource from the assignment too, I was still convinced that
div.one
anddiv.two
are on different levels of the existing stacking context hierarchy. But they are not. They are both nested inhtml
.So once I realized there are only two stacking contexts on the author's page —
html
andh1 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.Removing
position: relative
fromli
elements sets their position back to the default — static. It means thath1 span
's stacking context will finally work properly. Once the transition is triggered, it repaints that span without repainting any other unnecessary elements.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