This happened during the internal development of Jinghong’s image hosting service. A freshman reported that el-image and el-table were “clashing.”
Screenshot
Demo iframe:
When I saw that the table behind was showing through the el-image preview overlay, my first reaction was to ask the student to check whether the z-index was correct—specifically whether the el-image mask overlay had a higher z-index than the table.
After testing locally, I confirmed that the z-index was indeed set correctly. So why were the elements behind showing through? A quick Google search led me to this article:
Simply add the following CSS to
el-table:.el-table__cell { position: static !important; }
Testing locally confirmed that this solution works. But why? This is where Stacking Context comes into play.
What Exactly Is a Stacking Context?
Simply put, a Stacking Context is like a canvas. On the same canvas, elements with higher z-index values appear on top of those with lower values, which is why I initially suggested checking z-index. But the catch is that Stacking Contexts themselves have a hierarchy.
Imagine we have two canvases, A and B. On A, there’s an element with z-index: 1145141919810. This element has a very high priority and should appear at the very top of the browser window. But if canvas B has higher priority than canvas A, all elements on B will be displayed above A (essentially “winning by default”). So how is a canvas’s priority determined?
- Between sibling Stacking Contexts, priority is determined by
z-index. - For Stacking Contexts with the same
z-index, elements appearing later in the HTML document have higher priority.
The second rule explains why in the demo, only elements that come after the image cell in the table are showing through.
So Why Do el-image and el-table Clash?
This conflict is mainly caused by two factors:
el-tablesetsposition: relativefor each cell. Whenpositionis set torelative, the element creates a new Stacking Context.
image-20250531013029154
So a table with ten cells actually generates ten canvases, each withz-index: 1. According to the rules above, table cells that appear later in the HTML document have higher priority than the earlier image cell.- The overlay used by
el-image’s preview feature is placed inside theel-imageelement itself.
The orange area in the image above is the overlay used during preview. The default behavior of Element Plus is to insert the preview overlay inside the<el-image>tag. This traps the overlay inside a low-priority Stacking Context, allowing content from later table cells to appear on top.
So What’s the Solution?
Changing the position value works
The solution found online, forcing position: static on table cells, works because static does not create a new Stacking Context, avoiding the current problem.
Placing top-layer elements in the highest-priority context is more common
Other component libraries usually handle this by inserting the overlay directly into the body element and giving it a high z-index. This ensures it always appears on top of the screen (same principle used for dialogs, popovers, etc.).
In fact, Element Plus supports this feature:
preview-teleported: Determines whether the image viewer overlay is inserted into the
body. Should be set totrueif the parent element may modify its properties.
So using :preview-teleported="true" with el-image is a more robust approach, because we cannot guarantee that the parent of el-image (besides el-table cells) won’t create another Stacking Context.