Proposal for a z-layer property

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?

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 :

• https://css-tricks.com/handling-z-index/
• https://frontend.18f.gov/
• https://www.smashingmagazine.com/2014/06/sassy-z-index-management-for-complex-layouts/

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.