I don't know that you can really avoid z-index. You have to use it sooner or later anytime there's overlapping elements, and it's at least in common with every single UX design toolkit and animation software ever. But I agree that z-index 9999999 (or -999999) is terrible. There's gotta be a better way; but since there isn't, we live with it.
P.S. I find it rather ironic how much thinner "Good Parts" is to the "Javascript" book in the picture. Sums up my feelings on JS quite well, ha ha!
We can use SASS to overcome this problem, we can achieve that by making a separate file, let's call it z-indexes-defaults which will contain all the z-indexes definitions for the main elements that will overflow on each other or on the base content,
That will prevent us from facing such a problem and all your all z-indexes definitions are in one place and its values are represented by meaningful variables names
I don't know that you can really avoid z-index. You have to use it sooner or later anytime there's overlapping elements, and it's at least in common with every single UX design toolkit and animation software ever. But I agree that z-index
9999999(or-999999) is terrible. There's gotta be a better way; but since there isn't, we live with it.P.S. I find it rather ironic how much thinner "Good Parts" is to the "Javascript" book in the picture. Sums up my feelings on JS quite well, ha ha!
We can use SASS to overcome this problem, we can achieve that by making a separate file, let's call it z-indexes-defaults which will contain all the z-indexes definitions for the main elements that will overflow on each other or on the base content,
That will prevent us from facing such a problem and all your all z-indexes definitions are in one place and its values are represented by meaningful variables names
I dunno. Somehow this feels more icky than z-indices.
In the given example author managed to avoid using z-index for a modal. So I guess it is possible to do much less than we do typically.