Ĉu vi iam agordis z-indekson: 99999 sur elementon en via CSS, kaj ĝi ne aperas super aliaj elementoj? Valoro tiel granda devus facile loki tiun elementon vide sur io ajn alia, supozante ke ĉiuj malsamaj elementoj estas fiksitaj ĉe aŭ pli malalta valoro aŭ tute ne metitaj. Retpaĝo estas kutime reprezentita en dudimensia spaco; tamen, aplikante specifajn CSS-ecojn, imaga z-aksa ebeno estas lanĉita por transdoni profundon. Ĉi tiu ebeno estas perpendikulara al la ekrano, kaj de ĝi, la uzanto perceptas la ordon de elementoj, unu super la alia. La ideo malantaŭ la imaga z-akso, la percepto de la uzanto de stakitaj elementoj, estas ke la CSS-ecoj kiuj kreas ĝin kombinas por formi tion, kion ni nomas stakiga kunteksto. Ni parolos pri kiel elementoj estas "stakigitaj" sur retpaĝo, kio kontrolas la stakordon, kaj praktikajn alirojn por "malstaki" elementojn kiam necese. Pri Stakado de Kuntekstoj Imagu vian retpaĝon kiel skribtablo. Dum vi aldonas HTML-elementojn, vi metas paperpecojn, unu post la alia, sur la skribotablon. La lasta papero metita estas ekvivalenta al la plej lastatempe aldonita HTML-elemento, kaj ĝi sidas super ĉiuj aliaj paperoj metitaj antaŭ ĝi. Ĉi tio estas la normala dokumentfluo, eĉ por nestitaj elementoj. La skribotablo mem reprezentas la radikan stakan kuntekston, formitan de la elemento , kiu enhavas ĉiujn aliajn dosierujojn. Nun, specifaj CSS-ecoj eniras en ludon. Propraĵoj kiel pozicio (kun z-indekso), opakeco, transformo kaj enhavi) agas kiel dosierujo. Ĉi tiu dosierujo prenas elementon kaj ĉiujn ĝiajn filojn, ĉerpas ilin el la ĉefa stako kaj grupigas ilin en apartan substakon, kreante tion, kion ni nomas stakkunteksto. Por poziciigitaj elementoj, tio okazas kiam ni deklaras z-indeksan valoron krom aŭto. Por propraĵoj kiel opakeco, transformo kaj filtrilo, la stakkunteksto kreiĝas aŭtomate kiam specifaj valoroj estas aplikataj.
Provu kompreni ĉi tion: Post kiam peco de papero (t.e., infanelemento) estas ene de dosierujo (t.e., la stakkunteksto de la gepatro), ĝi neniam povas eliri tiun dosierujon aŭ esti metita inter paperoj en malsama dosierujo. Ĝia z-indekso nun estas nur grava ene de sia propra dosierujo.
En la suba ilustraĵo, Papero B nun estas en la stakkunteksto de Dosierujo B, kaj povas esti mendita nur kun aliaj artikoloj en la dosierujo.
Imagu, se vi volas, ke vi havas du dosierujojn sur via skribotablo:
.dosierujo-a { z-indekso: 1; } .dosierujo-b { z-indekso: 2; }
Ni iom ĝisdatigu la markadon. Ene de Dosierujo A estas speciala paĝo, z-indekso: 9999. Ene de Dosierujo B estas simpla paĝo, z-indekso: 5.
.special-paĝo { z-indekso: 9999; } .plain-page { z-indekso: 5; }
Kiu paĝo estas supre? Ĝi estas la .plain-paĝo en Dosierujo B. La retumilo ignoras la infanajn paperojn kaj stakas la du dosierujojn unue. Ĝi vidas Dosierujon B (z-indekso: 2) kaj metas ĝin supre de Dosierujo A (z-indekso: 1) ĉar ni scias, ke du estas pli granda ol unu. Dume, la .special-paĝo agordita al z-indekso: 9999 paĝo estas ĉe la malsupro de la stako kvankam ĝia z-indekso estas agordita al la plej alta ebla valoro. Stakantaj kuntekstoj ankaŭ povas esti nestitaj (dosierujoj ene de dosierujoj), kreante "genealogian arbon". La sama principo validas: infano neniam povas eskapi la dosierujon de siaj gepatroj. Nun kiam vi ekkomprenas kiel stakaj kuntekstoj kondutas kiel dosierujoj kiuj grupigas kaj reordigas tavolojn, indas demandi: kial certaj propraĵoj - kiel transformo kaj opakeco - kreas novajn stakajn kuntekstojn? Jen la afero: ĉi tiuj propraĵoj ne kreas stakajn kuntekstojn pro kiel ili aspektas; ili faras ĝin pro kiel la retumilo funkcias sub la kapuĉo. Kiam vi aplikas transformon, opakecon, filtrilon aŭ perspektivon, vi diras al la retumilo: "He, ĉi tiu elemento povus moviĝi, turniĝi aŭ velki, do estu preta!"
Kiam vi uzas ĉi tiujn trajtojn, la retumilo kreas novan stakan kuntekston por administri bildigon pli efike. Ĉi tio permesas al la retumilo pritrakti kuraĝigojn, transformojn kaj vidajn efikojn sendepende, reduktante la bezonon rekalkuli kiel ĉi tiuj elementoj interagas kun la resto de la paĝo. Pensu pri ĝi kiel la retumilo diranta: "Mi traktos ĉi tiun dosierujon aparte, por ke mi ne devu reorganizi la tutan skribotablon ĉiufoje kiam io en ĝi ŝanĝiĝas." Sed ekzistaskromefiko. Post kiam la retumilo levas elementon en sian propran tavolon, ĝi devas "platigi" ĉion ene de ĝi, kreante novan stakan kuntekston. Estas kiel preni dosierujon de la skribotablo por manipuli ĝin aparte; ĉio ene de tiu dosierujo estas grupigita, kaj la retumilo nun traktas ĝin kiel ununuran unuon kiam decidas kio sidas sur kio. Do kvankam la transformo- kaj opakecpropraĵoj eble ne ŝajnas influi la manieron, kiel la elementoj stakiĝas vide, ili faras, kaj ĝi estas por agado-optimumigo. Pluraj aliaj CSS-ecoj ankaŭ povas krei stakajn kuntekstojn pro similaj kialoj. MDN provizas kompletan liston se vi volas fosi pli profunde. Estas sufiĉe multaj, kiuj nur ilustras kiom facile estas pretervole krei stakan kuntekston sen scii ĝin. La "Malstaki" Problemo Stakaj problemoj povas ekesti pro multaj kialoj, sed iuj estas pli oftaj ol aliaj. Modalaj komponentoj estas klasika ŝablono ĉar ili postulas ŝanĝi la komponenton por "malfermi" sur supra tavolo super ĉiuj aliaj elementoj, tiam forigi ĝin de la supra tavolo kiam ĝi estas "fermita". Mi estas sufiĉe certa, ke ni ĉiuj renkontis situacion, kie ni malfermas modalon kaj, pro kia ajn kialo, ĝi ne aperas. Ne estas ke ĝi ne malfermiĝis ĝuste, sed ke ĝi estas ekster vido en pli malalta tavolo de la stakkunteksto. Ĉi tio lasas vin demandi "kiel do?" ĉar vi starigis:
.overlay { pozicio: fiksita; /* kreas la stakan kuntekston */ z-indekso: 1; /* metas la elementon sur tavolon super ĉio alia */ enmetita: 0; larĝo: 100%; alteco: 100vh; superfluo: kaŝita; fonkoloro: #00000080; }
Ĉi tio aspektas ĝusta, sed se la gepatra elemento enhavanta la modalan ellasilon estas infanelemento ene de alia gepatra elemento, kiu ankaŭ estas agordita al z-indekso: 1, tio teknike metas la modalon en subtavolon kaŝitan de la ĉefa dosierujo. Ni rigardu tiun specifan scenaron kaj kelkajn aliajn oftajn staki-kuntekstojn. Mi pensas, ke vi vidos ne nur kiom facile estas preterintence krei stakajn kuntekstojn, sed ankaŭ kiel mis administri ilin. Ankaŭ, kiel vi revenas al administrita ŝtato dependas de la situacio. Scenaro 1: La Kaptita Modalo
Vi povas tuj vidi vian modalon kaptitan en malaltnivela tavolo kaj identigi la gepatron. Retumilo-Etendoj Inteligentaj programistoj konstruis etendaĵojn por helpi. Iloj kiel ĉi tiu "CSS Stacking Context Inspector" Kroma etendo aldonas kroman z-indeksan langeton al viaj DevTools por montri al vi informojn pri elementoj, kiuj kreas stakan kuntekston.
IDE-Etendaĵoj Vi eĉ povas ekvidi problemojn dum disvolvado per etendaĵo kiel ĉi tiu por VS Code, kiu elstarigas eblajn stakigajn kuntekstojn rekte en via redaktilo.
Malstaki Kaj Reakiri Kontrolon Post kiam ni identigis la radikan kaŭzon, la sekva paŝo estas trakti ĝin. Estas pluraj aliroj, kiujn vi povas preni por trakti ĉi tiun problemon, kaj mi listigos ilin en ordo. Vi tamen povas elekti iun ajn je ajna nivelo; neniu povas plendi aŭ malhelpi alian. Ŝanĝu la HTML-Strukturon Ĉi tio estas konsiderata la optimuma solvo. Por ke vi renkontu kuntekstan problemon, vi devas meti kelkajn elementojn en amuzajn poziciojn ene de via HTML. Restrukturi la paĝon helpos vin transformi la DOM kaj forigi la stakan kuntekstan problemon. Trovu la probleman elementon kaj forigu ĝin de la kapta elemento en la HTML-markado. Ekzemple, ni povas solvi la unuan scenaron, "La Kaptita Modalo", movante la .modal-ujon el la kaplinio kaj metante ĝin en la elementon
per si mem.Kapo
Ĉefa Enhavo
Ĉi tiu enhavo havas z-indekson de 2 kaj ankoraŭ ne kovros la modalon.
Modala Titolo
Nun, mi ne estas malantaŭ io ajn. Mi akiris pli bonan pozicion kiel rezulto de DOM-restrukturado.
Kiam vi alklakas la butonon "Malfermu Modalon", la modalo estas poziciigita antaŭ ĉio alia kiel ĝi devas esti. Vidu la Plum-Scenaron 1: La Kaptita Modalo (Solvo) [forkigita] de Shoyombo Gabriel Ayomide. Alĝustigu LaGepatro Stacking Kunteksto En CSS Kio se la elemento estas tia, kiun vi ne povas movi sen rompi la aranĝon? Estas pli bone trakti la aferon: la gepatro establas la kuntekston. Trovu la CSS-posedaĵon (aŭ ecojn) respondecan por ekigi la kuntekston kaj forigu ĝin. Se ĝi havas celon kaj ne povas esti forigita, donu al la gepatro pli altan z-indeksan valoron ol ĝiaj gefrataj elementoj por levi la tutan ujon. Kun pli alta z-indeksa valoro, la gepatra ujo moviĝas al la supro, kaj ĝiaj infanoj aperas pli proksime al la uzanto. Surbaze de tio, kion ni lernis en la scenaro "The Submerged Dropdown", ni ne povas movi la falmenuon el la navbar; ĝi ne havus sencon. Tamen, ni povas pliigi la z-indeksan valoron de la .navbar-ujo por esti pli granda ol la z-indeksa valoro de la .content-elemento. .navbar { fono: #333; /* z-indekso: 1; */ z-indekso: 3; pozicio: parenco; }
Kun ĉi tiu ŝanĝo, la .dropdown-menuo nun aperas antaŭ la enhavo sen ajna problemo.
Vidu la Pen Scenaron 2: The Submerged Dropdown (Solvo) [forkigita] de Shoyombo Gabriel Ayomide.
Provu Portalojn, Se Uzanta Kadron
En kadroj kiel React aŭ Vue, Portalo estas trajto, kiu ebligas vin redoni komponanton ekster ĝia normala gepatra hierarkio en la DOM. Portaloj estas kiel teleportada aparato por viaj komponantoj. Ili permesas vin redoni HTML-on de komponento ie ajn en la dokumento (tipe ĝuste en document.body) konservante ĝin logike ligita al ĝia originala gepatro por apogoj, stato kaj eventoj. Ĉi tio estas perfekta por eviti stakajn kuntekstokaptilojn ĉar la eligita eligo laŭvorte aperas ekster la problema gepatra ujo.
ReactDOM.createPortal(
Ĉi tio certigas, ke via falmenuo enhavo ne estas kaŝita malantaŭ sia gepatro, eĉ se la gepatro havas superfluon: kaŝita aŭ pli malalta z-indekso. En la scenaro "La Tondita Tooltip", kiun ni rigardis pli frue, mi uzis Portalon por savi la konsileton de la superfluo: kaŝita klipo metante ĝin en la dokumentkorpon kaj poziciigante ĝin super la ellasilon ene de la ujo. Vidu la Plum-Scenaron 3: La Tondigita Ilotip (Solvo) [forkigita] de Shoyombo Gabriel Ayomide. Enkondukante Stakiga Kunteksto Sen Flankaj Efikoj Ĉiuj aliroj klarigitaj en la antaŭa sekcio celas "malstaki" elementojn de problemaj stakaj kuntekstoj, sed estas iuj situacioj, kie vi efektive bezonos aŭ volas krei stakigan kuntekston. Krei novan stakan kuntekston estas facila, sed ĉiuj aliroj venas kun kromefiko. Tio estas, krom uzi izolitecon: izoli. Se aplikite al elemento, la stakkunteksto de la infanoj de tiu elemento estas determinita relative al ĉiu infano kaj ene de tiu kunteksto, prefere ol esti influita per elementoj ekster ĝi. Klasika ekzemplo estas atribui al tiu elemento negativan valoron, kiel z-indekso: -1. Imagu, ke vi havas .card-komponenton. Vi volas aldoni ornaman formon, kiu sidas malantaŭ la teksto de la karto, sed sur la fono de la karto. Sen stakiga kunteksto sur la karto, z-indekso: -1 sendas la formon al la fundo de la radika stakiga kunteksto (la tuta paĝo). Ĉi tio malaperigas ĝin malantaŭ la blanka fono de la .card: Vidu la Pen Negativa z-indekso (problemo) [forkigita] de Shoyombo Gabriel Ayomide. Por solvi ĉi tion, ni deklaras izolitecon: izoli sur la gepatra .karto: Vidu la Pen Negativa z-indekso (solvo) [forkigita] de Shoyombo Gabriel Ayomide. Nun, la .card-elemento mem fariĝas stakiga kunteksto. Kiam ĝia infana elemento - la dekoracia formo kreita sur la pseŭdoelemento :before - havas z-indekson: -1, ĝi iras al la fundo de la stakkunteksto de la gepatro. Ĝi sidas perfekte malantaŭ la teksto kaj sur la fono de la karto, kiel celite. Konkludo Memoru: la venontan fojon, kiam via z-indekso ŝajnas neregebla, ĝi estas kaptita stakkunteksto. Referencoj
Stakiga kunteksto (MDN) Z-indekso kaj stakigaj kuntekstoj (web.dev) "Kiel Krei Novan Stakigan Kuntekston kun la Izola Propraĵo en CSS", Natalie Pina "Kio Diable, z-indekso?", Josh Comeau
Plia Legado Pri SmashingMag
"Administrado de CSS-Z-Indekso en Grandaj Projektoj", Steven Frieson "Glosiĝaj Headers Kaj Plenaltecaj Elementoj: Delikata Kombinaĵo", Philip Braunen "Administrado de Z-Indekso En Komponant-Bazita TTT-apliko", Pavel Pomerantsev "La Z-Indekso CSS-Nemoveblaĵo: Ampleksa Rigardo", Louis Lazaris
