Angenommen, Sie haben einen z-index-Bug. Etwas wird von etwas anderem überdeckt. Meiner Erfahrung nach besteht eine typische Lösung darin, position: relative auf das Element anzuwenden, damit z-index überhaupt funktioniert, und vielleicht den z-index-Wert anzupassen, bis das richtige Element darüber liegt.
Die Gefahr dabei ist, dass dies einen kleinen z-index-Krieg auslöst. Das Erhöhen eines z-index-Wertes dort behebt einen Fehler, verursacht aber dann einen anderen, indem es irgendwo anders ein anderes Element überdeckt, was Sie nicht wollten. Hoffentlich können Sie die Situation durchdenken und die Fehler beheben, auch wenn dies bedeutet, mehr z-index-Werte umzugestalten, als Sie ursprünglich dachten.
Wenn der "Stapel" von z-index-Werten kompliziert genug ist, können Sie eine Abstraktion in Betracht ziehen. Eines der Probleme ist, dass Ihre z-index-Werte wahrscheinlich eher zufällig über Ihr CSS verstreut sind. Anstatt dies einfach geschehen zu lassen, können Sie sich einen zentralen Ort für z-index-Werte einrichten, auf den Sie später verweisen können.
Ich habe das bereits als Sass-Map behandelt
$zindex: (
modal : 9000,
overlay : 8000,
dropdown : 7000,
header : 6000,
footer : 5000
);
.header {
z-index: map-get($zindex, header);
}
Nun haben Sie einen zentralen Ort, um diese Werte zu verwalten.
Rafi Strauss hat dies mit OZMap noch weiter getrieben. Es ist ebenfalls eine Sass-Map, die wie folgt konfiguriert ist:
$globalZIndexes: (
a: null,
b: null,
c: 2000,
d: null,
);
Die Idee hier ist, dass die meisten Werte vom Tool automatisch generiert werden (die null-Werte), Sie diese aber bei Bedarf angeben können. Auf diese Weise, wenn Sie eine Drittanbieterkomponente mit einem z-index-Wert haben, den Sie nicht ändern können, fügen Sie diesen in die Map ein, und die automatisch generierten Zahlen berücksichtigen dies, wenn Sie darüberliegende Ebenen erstellen. Es bedeutet auch, dass es sehr einfach ist, Ebenen dazwischen einzufügen.
Ich halte all das für clever und nützlich – aber ich denke auch, dass es bei einem anderen häufigen z-index-Bug nicht hilft: Stacking Contexts. Es ist immer der Stacking Context, wie ich geschrieben habe. Wenn sich ein Element in einem Stacking Context befindet, der unter einem anderen Stacking Context liegt, gibt es keinen möglichen z-index-Wert, der es darüber bringen kann. Das ist ein viel schwierigerer Fehler zu beheben.
Andy Blum hat kürzlich darüber geschrieben.
Eine der größten Frustrationen in der Frontend-Entwicklung sind die unerwarteten Interaktionen und Überlappungen derselben Elemente. Der Kampf um die Anordnung von Elementen auf der Z-Achse, die senkrecht durch den Computerbildschirm auf und vom Betrachter weg verläuft, ist eine so verbreitete Erfahrung im Frontend, dass der z-index eines Elements manchmal als Frustrations-Messgerät für die Stimmung des Entwicklers verwendet werden kann.
Der Schlüssel zu wartbaren z-index-Werten ist das Verständnis, dass z-index-Werte nicht immer direkt verglichen werden können. Sie sind keine absolute Messung auf einem imaginären Lineal, das aus dem Viewport herausragt; vielmehr ist es eine relative Reihenfolge zwischen Elementen innerhalb desselben Stacking Context.
Es stellt sich heraus, dass es ein nettes kleines Debugging-Tool für Stacking Contexts in Form einer Browser-Erweiterung gibt (Chrome und Firefox). Andy gerät in eine sehr knifflige Situation, in der eine RTL-Version (rechts-nach-links) einer Website eine Regel verwendet, die eine transform-Funktion nutzt, um ein Video auf der Seite zu verschieben. Diese transform-Funktion löst einen neuen Stacking Context aus und damit einen Bug mit einem nicht klickbaren Button. Gnarly.
Das bringt mich irgendwie dazu, dass es vielleicht eine integrierte DevTools-Möglichkeit geben könnte, Stacking Contexts zu sehen/zu verstehen. Ich weiß nicht, ob das die richtige Antwort ist, aber ich sehe immer mehr einen Trend zu "Badges" in DevTools. Diese Dinge

Tatsächlich hat Chrome 94 kürzlich ein neues für Container Queries veröffentlicht, also werden sie immer häufiger verwendet.
Vielleicht könnte es einen Badge für Stacking Contexts geben? Typischerweise, wenn Badges verwendet werden, klickt man sie an und es wird eine spezielle UI angezeigt. Zum Beispiel wird für Flexbox oder Grid die Überlagerung aller Grid-Linien angezeigt. Die spezielle UI für Stacking Contexts könnte farb-/texturcodiert und mit Beschriftungen versehen sein, die alle Stacking Contexts und ihre Schichtung zeigen.
Ich habe vor ein paar Jahren eine Lösung in Stylus geschrieben, die auf Kontexten basiert, und benutze sie immer noch.
https://github.com/acauamontiel/mantis-layers
Das hilft nicht unbedingt in Situationen mit Stacking Contexts, aber ich habe vor ein paar Monaten getwittert, dass z-index calc() und benutzerdefinierte Eigenschaften akzeptiert
https://www.joshwcomeau.com/css/stacking-contexts ist eine gute Lektüre zu diesem Thema.
Ich benutze
isolation: isolate, um neue Stacking Contexts (ohne Nebeneffekte) zu erstellen, seit ich diesen Beitrag gelesen habe.Nun, Chrome hat den Layers-Tab in DevTools schon seit einer Ewigkeit, er hat sogar eine 3D-Darstellung der Seite (die nicht sehr nützlich ist).
Aber ich stimme zu, dass er in den neuen Layout-Tab übernommen und etwas aufgepeppt werden sollte.
Um mich selbst zu zitieren, habe ich einmal einen
z-index-Bug behoben, indem ich Elemente im DOM verschoben habe. Es lohnt sich, darauf hinzuweisen, da mein erster Instinkt war, mit dem Stacking Context zu spielen.https://www.bennadel.com/blog/4113-organizing-my-application-layers-using-z-index-stacking-contexts-in-css.htm