[css-view-transitions-1] Named elements appear above fixed elements when transitioning

[danchristofi]

Please see the following codepen: https://codepen.io/danchristofi/pen/abQzMLM

<button id="show">Show box</button>
<div id="box"></div>
<footer class="footer"></footer>

#box {
  width: 300px;
  height: 2000px;
  background: #000;
  display: none;
  view-transition-name: box;
}

.footer {
  position: fixed;
  width: 100%;
  height: 100px;
  background: red;
  bottom: 0;
  left: 0;
  z-index: 100;
  view-transition-name: footer;
}

.visible {
  display: block !important;
}

::view-transition-old(box),
::view-transition-new(box) {
  animation-duration: 10s;
}

document.getElementById("show").addEventListener("click", () => {
  document.startViewTransition(() => {
    document.getElementById("box").classList.toggle('visible')
  })
})

When adding a class to make the box visible, it appears over the top of the fixed element. In this example the red bar is fixed to the bottom of the page with the box behind it. After the animation is finished the box returns behind the footer.

Removing the view-transition-name from the box stops this happening, but it would be needed if you want a custom animation.

Is this a bug or is there any extra styling needed to get this to work correctly?

[khushalsagar]

Unfortunately, this is the API working as intended. View Transition has to figure out how to animate multiple aspects of the DOM changing. One of those is the paint order which can't be interpolated so we had to pick some paint order. And the way it works is:

• First paint all the view-transition-names in the old DOM, in the order in which they are painted in the old DOM.
• Then paint all the view-transition-names which are only in the new DOM, in the order in which they are painted in the new DOM.

The paint order here derives from the DOM order of ::view-transition-group pseudo-elements.

In this case box is only in the new DOM (we ignore elements with a view-transition-name if they are display: none), so it paints on top of all view-transition-names from the old DOM which includes the footer. The fix is simple, you can use z-index to define the paint order of the group pseudos:

::view-transition-group(footer) {
  z-index: 100;
}

One approach we could try would be something like :

• Figure out the paint order of elements in the old DOM. Say its [A, B, C].
• Figure out the paint order of elements in the new DOM. Say its [A, D, B, C].

Then combine these in the best way possible. For example, in the above case [A, D, B, C] would make sense. But if the 2 lists are [A, B, C] and [A, D] then its not clear what the ordering should be. Current spec would do [A, B, C, D] which seems fine, authors can always use z-index to fix the paint order.

I'm open to suggestion here, not sure if the pattern in this issue is common enough for us to change the way we order the pseudos vs chalking it up to an edge case where authors should use z-index.

[khushalsagar]

Gonna close this, we'll need a fairly complicated algorithm for deciding the paint order here to get every case right. Since there is an easy way for authors to do this way, with a primitive that's meant for this purpose, it doesn't feel worth it.

[tounsoo]

Any new development on this topic? I'm having this issue.

[bramus]

Scoped View Transitions will allow you to solve this: you’d start a View Transition on an element that excludes the position: fixed element. Scoped View Transitions are currently being prototyped in Chromium (announcement).

In the mean time, you can work around it by giving the element that is position: fixed a view-transition-name as well.