by Stephanie Eckles Have you ever tried to set z-index: 9999 to solve element layering issues? If so, you’ve been fighting a fundamental CSS concept of stacking contexts. The stacking context defines the order things are placed in the third dimension, or the “z” axis. Think of the z-axis as layers of DOM elements between the root of the stacking context within the viewport, and you, the user, looking through the browser viewport. An element can only be re-layered within the same stacking context. While z-index is the tool to do it, the failure happens due to a change in stacking contexts. This can happen in a few ways, such as a fixed or sticky positioned element, or combining position absolute or relative along with a z-index, among others as listed on MDN. A modern web feature is the “top layer,” which is guaranteed to be the top-most layer above any other stacking context. It spans the entire viewport, although elements existing in the top layer may have smaller visible dimensions. Promoting an element to the top layer breaks it free of any stacking context it may otherwise exist within. Although the top layer directly addresses a CSS-related issue, there is currently no property available to promote an element to the top layer. Instead, certain elements and conditions gain access to the top layer, including native dialogs via showModal() and elements designated as popovers. The Popover API is a newly available HTML feature that enables you to create declarative non-modal overlay elements. The ability to escape any stacking context by gaining top layer access is usually a desirable feature of choosing the Popover API. However, there’s a sneaky potential conflict to be aware of before hastily opting for this native upgrade. Setting the scene Picture this, the web, 2025: your web app includes a notification service that displays via “toast” messages. You know, those pop-up messages that usually appear in a corner or other location with a lower likelihood of...