A common problem with z-index is the misuse of this by advertising. This creates bugs when developing navigation, modals, panels etc especially as 3rd party scripts are often turned off for development.
I propose a z-layer property to name-space z-index values and help prevent ever increasing indexes. An accompanying property might be z-layers: key value where the key is the z-layer-name and the value is the accompanying z-layer-index.
The point being, that an element set within a z-layer-index of 1 can be higher than an element within a z-layer-index of 2 (no matter the z-index). Giving names to these layers allows 3rd parties to set there content appropriately and the the developer to place that layer where it is needed within the app.
more details:
@tabatkins - anyone from CSS that we could ping to have a look at this?
Iām not sure if it is a good idea. Do that many people really have this z-index problem? And if they do, should they not just fix the z-index war theyāve started themselves? 
1 Like
Itās a valid question, but I was trying to point out at that often it is not within a single teams power to change this.
Once a team consumes external code (from npm, another team or via ads) then it is not always straight forward or quick to get these things fixed - if possible at all. Often, once CSS is committed people are very scared to change it in-case it breaks other things, which means these things donāt ever get prioritised and the problem just grows.
With a z-layer, we could āboxā these externals into a space where they can behave as they like, without affecting our internal code.
I donāt feel like the layer is a hack to a hack, but a solution to an existing problem. Other solutions to this issue has come about using Sass etc :
I think the true solution could me made better if this part of CSS was to be re-imagined.
I just think creating a solution to a problem that shouldnāt exist by introducing ways that could likely exacerbate the problem may not be the best path forward here.
To clarify, I donāt necessarily think that what youāre proposing is a āhackā. But by introducing more layers (no pun intended), weāre essentially encouraging developers to circumvent the whole reason z-layers were introduced to begin with.
If it is true that the packages you are using is the cause of z-index conflicts (Iāve never had this problem with any credible packages that Iāve used btw), I would just open a PR on that packages repository or perhaps use a better package.
FWIW, Iām a firm believer in giving the people what they want. So if there are many developers who run into this problem and think your solution is necessary, we probably should move forward with it. So thatās why I was curious of knowing if this is really a huge problem youāre trying to solve or if it is more rare than you think.
Thereās a good case for the ability to sandbox an element (which might
be inserted server-side or in JavaScript), providing control over CSS
inheritance as well as scripts and other objects, and perhaps iframe-
like creating a new restricted viewport.
I think that may be a better way forward than trying to replace
individual properties.
Even with your proposal, itād be easy to write a script to find the
highest currently-used layer name and make a new one.
1 Like
