Har du nogensinde sat z-index: 99999 på et element i din CSS, og det kommer ikke ud oven på andre elementer? En værdi, der er stor, bør nemt placere elementet visuelt oven på noget andet, forudsat at alle de forskellige elementer er sat til enten en lavere værdi eller slet ikke indstillet. En webside er normalt repræsenteret i et todimensionelt rum; ved at anvende specifikke CSS-egenskaber introduceres et imaginært z-akseplan for at formidle dybde. Dette plan er vinkelret på skærmen, og fra det opfatter brugeren rækkefølgen af elementer, det ene oven på det andet. Ideen bag den imaginære z-akse, brugerens opfattelse af stablede elementer, er, at de CSS-egenskaber, der skaber den, kombineres for at danne det, vi kalder en stacking-kontekst. Vi vil tale om, hvordan elementer "stables" på en webside, hvad der styrer stablingsrækkefølgen og praktiske tilgange til at "afstable" elementer, når det er nødvendigt. Om stablingskontekster Forestil dig din webside som et skrivebord. Når du tilføjer HTML-elementer, lægger du stykker papir, det ene efter det andet, på skrivebordet. Det sidste stykke papir, der er placeret, svarer til det senest tilføjede HTML-element, og det ligger oven på alle de andre papirer, der er placeret før det. Dette er det normale dokumentflow, selv for indlejrede elementer. Selve skrivebordet repræsenterer rodstablingskonteksten, dannet af -elementet, som indeholder alle andre mapper. Nu kommer specifikke CSS-egenskaber i spil. Egenskaber som position (med z-indeks), opacitet, transformation og contain) fungerer som en mappe. Denne mappe tager et element og alle dets underordnede elementer, uddrager dem fra hovedstakken og grupperer dem i en separat understak, hvilket skaber det, vi kalder en stablingskontekst. For positionerede elementer sker dette, når vi erklærer en anden z-indeksværdi end auto. For egenskaber som opacitet, transformation og filter oprettes stablingskonteksten automatisk, når specifikke værdier anvendes.
Prøv at forstå dette: Når først et stykke papir (dvs. et underordnet element) er inde i en mappe (dvs. forældrenes stablekontekst), kan det aldrig forlade denne mappe eller placeres mellem papirer i en anden mappe. Dens z-indeks er nu kun relevant i sin egen mappe.
I nedenstående illustration er papir B nu i stablekonteksten af mappe B og kan kun bestilles med andre papirer i mappen.
Forestil dig, om du vil, at du har to mapper på dit skrivebord:
.folder-a { z-indeks: 1; } .mappe-b { z-indeks: 2; }
Lad os opdatere markeringen lidt. Inde i mappe A er en speciel side, z-indeks: 9999. Inde i mappe B er en almindelig side, z-indeks: 5.
.special-page { z-indeks: 9999; } .plain-page { z-indeks: 5; }
Hvilken side er øverst? Det er .plain-siden i mappe B. Browseren ignorerer de underordnede papirer og stabler de to mapper først. Den ser mappe B (z-indeks: 2) og placerer den oven på mappe A (z-indeks: 1), fordi vi ved, at to er større end én. I mellemtiden er .special-page sat til z-index: 9999 siden i bunden af stakken, selvom dens z-indeks er indstillet til den højest mulige værdi. Stablekontekster kan også indlejres (mapper inde i mapper), hvilket skaber et "slægtstræ". Det samme princip gælder: et barn kan aldrig undslippe sine forældres mappe. Nu hvor du ved, hvordan stablingskontekster opfører sig som mapper, der grupperer og omorganiserer lag, er det værd at spørge: hvorfor skaber visse egenskaber - såsom transformation og opacitet - nye stablingskontekster? Her er sagen: Disse egenskaber skaber ikke stablekontekster på grund af, hvordan de ser ud; de gør det på grund af, hvordan browseren fungerer under motorhjelmen. Når du anvender transformation, opacitet, filter eller perspektiv, fortæller du browseren: "Hey, dette element kan flytte, rotere eller falme, så vær klar!"
Når du bruger disse egenskaber, opretter browseren en ny stablingskontekst for at administrere gengivelsen mere effektivt. Dette gør det muligt for browseren at håndtere animationer, transformationer og visuelle effekter uafhængigt, hvilket reducerer behovet for at genberegne, hvordan disse elementer interagerer med resten af siden. Tænk på det som browseren, der siger: "Jeg håndterer denne mappe separat, så jeg ikke behøver at blande hele skrivebordet om, hver gang noget i den ændrer sig." Men der eren bivirkning. Når først browseren løfter et element ind i sit eget lag, skal den "flade" alt i det og skabe en ny stakkontekst. Det er som at tage en mappe fra skrivebordet for at håndtere den separat; alt inde i den mappe bliver grupperet, og browseren behandler det nu som en enkelt enhed, når den beslutter, hvad der skal være oven i hvad. Så selvom transformations- og opacitetsegenskaberne måske ikke ser ud til at påvirke den måde, elementer stables visuelt på, gør de det, og det er for optimering af ydeevnen. Flere andre CSS-egenskaber kan også skabe stablingskontekster af lignende årsager. MDN giver en komplet liste, hvis du vil grave dybere. Der er en del, som kun illustrerer, hvor nemt det er uforvarende at skabe en stablekontekst uden at vide det. Problemet med "Udstabling". Stablingsproblemer kan opstå af mange årsager, men nogle er mere almindelige end andre. Modale komponenter er et klassisk mønster, fordi de kræver at skifte komponenten til at "åbne" på et øverste lag over alle andre elementer og derefter fjerne det fra det øverste lag, når det er "lukket". Jeg er ret overbevist om, at vi alle er løbet ind i en situation, hvor vi åbner en modal, og uanset årsagen vises den ikke. Det er ikke, at den ikke åbnede ordentligt, men at den er ude af syne i et lavere lag af stablekonteksten. Dette efterlader dig til at spekulere på "hvordan kommer det?" siden du har indstillet:
.overlay { position: fast; /* opretter stablekonteksten */ z-indeks: 1; /* sætter elementet på et lag over alt andet */ indsat: 0; bredde: 100%; højde: 100vh; overløb: skjult; baggrundsfarve: #00000080; }
Dette ser korrekt ud, men hvis det overordnede element, der indeholder den modale trigger, er et underordnet element i et andet overordnet element, der også er indstillet til z-index: 1, som teknisk placerer modalen i et underlag, der er skjult af hovedmappen. Lad os se på det specifikke scenarie og et par andre almindelige faldgruber i stablingskontekst. Jeg tror, at du ikke kun vil se, hvor nemt det er utilsigtet at skabe stacking-kontekster, men også hvordan man fejlforvalter dem. Hvordan du vender tilbage til en administreret tilstand afhænger også af situationen. Scenario 1: The Trapped Modal
Du kan straks se din modal fanget i et lavt niveau og identificere forælderen. Browserudvidelser Smarte udviklere har bygget udvidelser til at hjælpe. Værktøjer som denne "CSS Stacking Context Inspector" Chrome-udvidelse tilføjer en ekstra z-index-fane til dine DevTools for at vise dig oplysninger om elementer, der skaber en stablingskontekst.
IDE-udvidelser Du kan endda se problemer under udvikling med en udvidelse som denne til VS Code, som fremhæver potentielle stablingskontekstproblemer direkte i din editor.
Afstabling og genvinde kontrol Når vi har identificeret årsagen, er næste skridt at håndtere det. Der er flere tilgange, du kan tage for at løse dette problem, og jeg vil liste dem i rækkefølge. Du kan dog vælge hvem som helst på ethvert niveau; ingen kan klage eller hindre en anden. Skift HTML-strukturen Dette anses for at være den optimale løsning. For at du kan løbe ind i et stablingskontekstproblem, skal du have placeret nogle elementer i sjove positioner i din HTML. Omstrukturering af siden vil hjælpe dig med at omforme DOM og eliminere stablingskontekstproblemet. Find det problematiske element, og fjern det fra fældeelementet i HTML-markeringen. For eksempel kan vi løse det første scenarie, "The Trapped Modal", ved at flytte .modal-containeren ud af headeren og placere den i
-elementet af sig selv.Dette indhold har et z-indeks på 2 og vil stadig ikke dække modal.Overskrift
Hovedindhold
Når du klikker på knappen "Åbn modal", er modalen placeret foran alt andet, som det skal være. Se Pen Scenario 1: The Trapped Modal (Solution) [forked] af Shoyombo Gabriel Ayomide. JusterForældrestablingskontekst i CSS Hvad hvis elementet er et, du ikke kan flytte uden at bryde layoutet? Det er bedre at tage fat på problemet: forælderen etablerer konteksten. Find den CSS-egenskab (eller -egenskaber), der er ansvarlig for at udløse konteksten, og fjern den. Hvis det har et formål og ikke kan fjernes, skal du give forælderen en højere z-indeksværdi end dens søskendeelementer for at løfte hele beholderen. Med en højere z-indeksværdi flyttes den overordnede container til toppen, og dens børn vises tættere på brugeren. Baseret på, hvad vi lærte i "The Submerged Dropdown"-scenariet, kan vi ikke flytte dropdown-menuen ud af navigeringslinjen; det ville ikke give mening. Vi kan dog øge z-indeksværdien af .navbar-beholderen til at være større end .content-elementets z-indeksværdi. .navbar { baggrund: #333; /* z-indeks: 1; */ z-indeks: 3; stilling: relativ; }
Med denne ændring vises .dropdown-menuen nu foran indholdet uden problemer.
Se Pen Scenario 2: The Submerged Dropdown (Solution) [forked] af Shoyombo Gabriel Ayomide.
Prøv portaler, hvis du bruger en ramme
I rammer som React eller Vue er en portal en funktion, der lader dig gengive en komponent uden for dens normale overordnede hierarki i DOM. Portaler er som en teleporteringsenhed til dine komponenter. De lader dig gengive en komponents HTML hvor som helst i dokumentet (typisk lige ind i document.body), mens du holder den logisk forbundet med dens oprindelige forælder for rekvisitter, tilstand og begivenheder. Dette er perfekt til at undslippe stablingskontekstfælder, da det gengivede output bogstaveligt talt vises uden for den problematiske overordnede container.
ReactDOM.createPortal(
Dette sikrer, at dit dropdown-indhold ikke er skjult bag sin forælder, selvom forælderen har overløb: skjult eller et lavere z-indeks. I scenariet "Det afklippede værktøjstip", vi så på tidligere, brugte jeg en portal til at redde værktøjstip fra overløbet: skjult klip ved at placere det i dokumentets krop og placere det over udløseren i beholderen. Se Pen Scenario 3: The Clipped Tooltip (Solution) [forked] af Shoyombo Gabriel Ayomide. Introduktion til stablingskontekst uden bivirkninger Alle de tilgange, der blev forklaret i det foregående afsnit, er rettet mod at "afstable" elementer fra problematiske stablingskontekster, men der er nogle situationer, hvor du faktisk har brug for eller ønsker at skabe en stablingskontekst. Det er nemt at skabe en ny stablingskontekst, men alle tilgange har en bivirkning. Det vil sige, bortset fra at bruge isolation: isolere. Når den anvendes på et element, bestemmes stablekonteksten for det elements børn i forhold til hvert barn og inden for den kontekst, snarere end at blive påvirket af elementer uden for det. Et klassisk eksempel er at tildele det element en negativ værdi, såsom z-indeks: -1. Forestil dig, at du har en .card-komponent. Du vil tilføje en dekorativ form, der sidder bag .cards tekst, men oven på kortets baggrund. Uden en stablingskontekst på kortet sender z-index: -1 formen til bunden af rodstablingskonteksten (hele siden). Dette får det til at forsvinde bag .cards hvide baggrund: Se Pen Negative z-indeks (problem) [forked] af Shoyombo Gabriel Ayomide. For at løse dette erklærer vi isolation: isolate på det overordnede .card: Se Pen Negative z-indeks (løsning) [forked] af Shoyombo Gabriel Ayomide. Nu bliver .card-elementet i sig selv en stablekontekst. Når dets underordnede element - den dekorative form skabt på :before pseudo-elementet - har z-indeks: -1, går det helt til bunds i forældrenes stablekontekst. Det sidder perfekt bag teksten og oven på kortets baggrund, efter hensigten. Konklusion Husk: næste gang dit z-indeks ser ud til at være ude af kontrol, er det en fanget stablingskontekst. Referencer
Stablingskontekst (MDN) Z-indeks og stablingskontekster (web.dev) "Sådan opretter du en ny stablingskontekst med isolationsegenskaben i CSS", Natalie Pina "Hvad pokker, z-indeks?", Josh Comeau
Yderligere læsning om SmashingMag
"Managing CSS Z-Index i store projekter", Steven Frieson "Sticky Headers And Full-Height Elements: A Tricky Combination", Philip Braunen "Administration af Z-indeks i en komponentbaseret webapplikation", Pavel Pomerantsev "The Z-Index CSS Property: A Comprehensive Look", Louis Lazaris
