Сиз качандыр бир жолу z-index: 99999 CSS'иңиздин элементине койдуңуз беле, бирок ал башка элементтердин үстүнө чыкпай калдыбы? Чоң маани ошол элементти визуалдык түрдө башка нерсенин үстүнө оңой эле жайгаштырышы керек, эгерде бардык ар кандай элементтер төмөнкү мааниге коюлган же такыр коюлбаган болсо. Веб-баракча адатта эки өлчөмдүү мейкиндикте көрсөтүлөт; бирок, конкреттүү CSS касиеттерин колдонуу менен тереңдикти берүү үчүн элестүү z огу тегиздиги киргизилет. Бул тегиздик экранга перпендикуляр жана андан колдонуучу элементтердин биринин үстүнө бири-бирине жайгашуусун кабыл алат. Элестетилген z огунун артында турган идея, колдонуучунун топтолгон элементтерди кабылдоосу, аны түзгөн CSS касиеттери биригип, биз стектөө контексти деп атаган нерсени түзөт. Элементтер веб-баракчага кантип "үйлөнгөнү", тизүү тартибин эмне көзөмөлдөй турганы жана керек болгондо элементтерди "чогуу" боюнча практикалык ыкмалар жөнүндө сүйлөшөбүз. Stacking контексттери жөнүндө Веб баракчаңызды үстөл катары элестетиңиз. HTML элементтерин кошкондо, сиз кагаздарды биринин артынан бири столго коюп жатасыз. Акыркы жайгаштырылган кагаз эң акыркы кошулган HTML элементине барабар жана ал анын алдына коюлган бардык башка кагаздардын үстүнө отурат. Бул уяланган элементтер үчүн да кадимки документ агымы. Үстөлдүн өзү башка бардык папкаларды камтыган элементи тарабынан түзүлгөн түпкү сток контекстти билдирет. Эми, белгилүү CSS касиеттери оюнга кирет. Позиция (z-индекс менен), тунуктук, трансформация жана камтышы сыяктуу касиеттер папка сыяктуу иштейт. Бул папка элементти жана анын бардык балдарын алып, аларды негизги стектен чыгарып, өзүнчө субстекке топтоп, биз стектөө контексти деп атаган нерсени жаратат. Орнотулган элементтер үчүн бул биз auto эмес, z-индекс маанисин жарыялаганда болот. Тунук эместик, трансформация жана чыпкалоо сыяктуу касиеттер үчүн атайын маанилер колдонулганда стектөө контексти автоматтык түрдө түзүлөт.
Муну түшүнүүгө аракет кылыңыз: бир барак кагаз (б.а., бала элемент) папканын ичине киргенден кийин (б.а., ата-эненин топтоо контексти), ал эч качан ал папкадан чыга албайт же башка папкадагы кагаздардын арасына жайгаштырылбайт. Анын z-индекс азыр өзүнүн папкасынын ичинде гана тиешелүү.
Төмөнкү сүрөттө, В кагазы азыр В папкасынын стектелүү контекстинде жана папкадагы башка кагаздар менен гана буйрутма берсе болот.
Кааласаңыз, столуңузда эки папка бар экенин элестетиңиз:
.folder-a { z-индекс: 1; } .folder-b {z-индекс: 2; }
Келгиле, белгини бир аз жаңырталы. А папкасынын ичинде атайын барак, z-индекс: 9999. В папкасынын ичинде жөнөкөй барак, z-индекс: 5.
.special-page {z-индекс: 9999; } .plain-page {z-index: 5; }
Кайсы бет башында турат? Бул В папкасындагы .plain-бет. Браузер бала кагаздарды этибарга албай, адегенде эки папканы топтойт. Ал В папкасын көрөт (z-индекс: 2) жана аны А папкасынын үстүнө жайгаштырат (z-индекс: 1), анткени экөө бирден чоң экенин билебиз. Ошол эле учурда, .special-page z-index: 9999 деп коюлган барак, анын z-индекси мүмкүн болгон эң жогорку мааниге коюлганына карабастан, стектин ылдый жагында. Стекинг контексттерин уя салып (папкалардын ичиндеги папкалар), "үй-бүлө дарагын" түзсө болот. Ошол эле принцип колдонулат: бала эч качан ата-энесинин папкасынан чыга албайт. Эми сиз катмарларды топтоочу жана иретке келтирүүчү папкалар сыяктуу стектилөө контексттери кандай иштээрин түшүнгөнүңүздөн кийин, төмөнкү суроолорду бериш керек: эмне үчүн трансформация жана тунук эместик сыяктуу кээ бир касиеттер жаңы контексттерди түзүшөт? Бул жерде бир нерсе: бул касиеттер сырткы көрүнүшүнө байланыштуу контексттерди түзбөйт; алар муну браузердин капоттун астында кантип иштегени үчүн жасашат. Трансформацияны, тунуктукту, чыпкалоону же перспективаны колдонгондо, сиз браузерге: "Эй, бул элемент жылып, айланып же өчүп калышы мүмкүн, андыктан даяр бол!"
Бул касиеттерди колдонгондо, браузер көрсөтүүнү эффективдүү башкаруу үчүн жаңы стекинг контекстти түзөт. Бул браузерге анимацияларды, трансформацияларды жана визуалдык эффекттерди өз алдынча башкарууга мүмкүндүк берип, бул элементтердин барактын калган бөлүгү менен өз ара аракеттенүүсүн кайра эсептөө зарылдыгын азайтат. Муну браузердин "Мен бул папканы өзүнчө иштетем, андыктан анын ичиндеги бир нерсе өзгөргөн сайын столдун баарын өзгөртүп салбайм" деп ойлоп көрүңүз. Бирок барa side effect. Браузер элементти өзүнүн катмарына көтөргөндөн кийин, ал андагы бардык нерсени "тегиздетип", жаңы стекинг контекстти түзүшү керек. Бул өзүнчө иштетүү үчүн столдон бир папканы алуу сыяктуу; ал папканын ичиндеги бардык нерселер топтолот жана браузер эми эмненин үстүндө эмне турганын чечүүдө аны бирдиктүү бирдик катары карайт. Ошентип, трансформация жана тунуктук касиеттери элементтердин визуалдык түрдө стектөө ыкмасына таасир этпесе да, алар эффективдүүлүктү оптималдаштыруу үчүн. Бир нече башка CSS касиеттери да ушул сыяктуу себептерден улам стекинг контексттерин түзө алат. Эгер тереңирээк казгыңыз келсе, MDN толук тизмени берет. Бир нечеси бар, алар байкабай туруп контекстти түзүү канчалык оңой экенин көрсөтүп турат. "Чыгуу" көйгөйү Стекинг маселелери көптөгөн себептерден улам пайда болушу мүмкүн, бирок алардын айрымдары башкаларга караганда көбүрөөк кездешет. Модалдык компоненттер классикалык үлгү болуп саналат, анткени алар компонентти башка бардык элементтердин үстүндөгү үстүнкү катмарда "ачуу" үчүн которуштурууну, андан кийин "жабык" болгондо аны үстүнкү катмардан алып салууну талап кылат. Мен баарыбыз бир модалды ачкан кырдаалга туш болдук жана кандайдыр бир себептерден улам ал көрүнбөй калганына ишенем. Бул анын туура ачылбаганында эмес, бирок сток контекстинин төмөнкү катмарында көрүнбөй калганында. Бул сизди "кандайча болду?" деп таң калтырат. since you set:
.overlay { орду: туруктуу; /* стекинг контекстти түзөт */ z-index: 1; /* элементти баарынан жогору катмарга коёт */ inset: 0; туурасы: 100%; бийиктиги: 100vh; overflow: hidden; background-color: #00000080; }
Бул туура көрүнөт, бирок модалдык триггерди камтыган негизги элемент z-индекс: 1ге орнотулган башка ата-энелик элементтин ичиндеги бала элемент болсо, бул техникалык жактан модалды негизги папка менен көмүскөдө калган субкатмарга жайгаштырат. Келгиле, ошол конкреттүү сценарийди жана башка бир нече жалпы контексттик тузактарды карап көрөлү. Сиз байкабай контексттерди түзүү канчалык оңой экенин гана эмес, аларды кантип туура эмес башкарууну да көрөсүз деп ойлойм. Ошондой эле, сиз башкарылган абалга кантип кайтууңуз кырдаалга жараша болот. 1-сценарий: Капкан модаль
Модалыңыздын төмөнкү деңгээлдеги катмарга камалып калганын дароо көрүп, ата-энени аныктай аласыз. Browser Extensions Акылдуу иштеп чыгуучулар жардам берүү үчүн кеңейтүүлөрдү түзүштү. Ушул "CSS Stacking Context Inspector" Chrome кеңейтүүсү сыяктуу куралдар, стекке контекстти түзгөн элементтер жөнүндө маалыматты көрсөтүү үчүн DevTools'уңузга кошумча z-индекс өтмөктү кошот.
IDE Extensions Сиз VS Code үчүн ушуга окшогон кеңейтүү менен иштеп чыгуу учурунда көйгөйлөрдү байкай аласыз, ал түз эле редакторуңузда мүмкүн болгон стекинг контексттик маселелерин баса белгилейт.
Чыгаруу жана башкарууну калыбына келтирүү Биз негизги себебин аныктагандан кийин, кийинки кадам аны менен күрөшүү болуп саналат. Бул көйгөйдү чечүү үчүн бир нече ыкмаларды колдонсоңуз болот, мен аларды ирети менен тизмелеп берем. Сиз каалаган деңгээлде каалаган адамды тандай аласыз; эч ким башкасына нааразы боло албайт же тоскоол боло албайт. HTML түзүмүн өзгөртүү Бул оптималдуу оңдоо деп эсептелет. Сиз контексттик көйгөйгө туш болушуңуз үчүн, сиз HTML ичинде кээ бир элементтерди күлкүлүү орундарга жайгаштырган болушуңуз керек. Баракты реструктуризациялоо сизге DOMды өзгөртүүгө жана контексттик стекерлик көйгөйдү жок кылууга жардам берет. Көйгөйлүү элементти табыңыз жана аны HTML белгилөөсүндө кармоочу элементтен алып салыңыз. Мисалы, биз .modal-контейнерди баш колонкадан жылдырып жана аны
элементине өзү эле жайгаштыруу менен, биринчи сценарийди, "Капкан модалды" чече алабыз.Бул мазмундун z-индекс 2 жана дагы эле модалды камтыбайт.Header
Main Content
"Модалды ачуу" баскычын басканда, модаль болушу керек болгон бардык нерсенин алдында жайгашат. 1-калем сценарийин караңыз: Тузакта калган модаль (чечим) [айрылуу] Шойомбо Габриэль Айомиде. Adjust TheCSS'те ата-эне контексти Эгер элемент макетти бузбастан жыла албай турган болсочу? Бул маселени чечүү үчүн жакшыраак: ата-эне контекстти белгилейт. Контекстти козгоо үчүн жооптуу CSS касиетин (же касиеттерин) таап, аны алып салыңыз. Эгер анын максаты болсо жана аны алып салуу мүмкүн болбосо, бүт контейнерди көтөрүү үчүн ата-энеге анын бир тууган элементтерине караганда жогорураак z-индекс маанисин бериңиз. Жогорку z-индекс мааниси менен ата-энелик контейнер жогоруга жылат жана анын балдары колдонуучуга жакыныраак көрүнөт. "Суу астында калган ылдый ылдый" сценарийинде үйрөнгөн нерселерибиздин негизинде, биз ачылуучу тизмени навигация тилкесинен жылдыра албайбыз; бул маанисиз болмок. Бирок, биз .navbar контейнеринин z-индекстин маанисин .content элементинин z-индекс маанисинен чоңураак кылып жогорулата алабыз. .navbar { фон: #333; /* z-index: 1; */ z-index: 3; position: relative; }
Бул өзгөртүү менен, .ашылма меню азыр эч кандай көйгөйсүз мазмундун алдында пайда болот.
2-калем сценарийин караңыз: Суу астында калган түшүүчү ылдый (Чечим) [айрылуу] Шойомбо Габриэл Айомиде.
Алкак колдонсоңуз, порталдарды байкап көрүңүз
React же Vue сыяктуу алкактарда Портал бул DOMдеги кадимки ата-эне иерархиясынан тышкары компонентти көрсөтүүгө мүмкүндүк берген функция. Порталдар сиздин компоненттериңиз үчүн телепортация аппараты сыяктуу. Алар документтин каалаган жеринде (адатта документ.body ичине) компоненттин HTML'син көрсөтүүгө мүмкүндүк берет, ошол эле учурда аны реквизиттер, абал жана окуялар үчүн баштапкы ата-энеси менен логикалык жактан байланыштырат. Бул контексттик тузактан кутулуу үчүн эң сонун, анткени көрсөтүлгөн чыгаруу түзмө-түз көйгөйлүү ата-энелик контейнердин сыртында пайда болот.
ReactDOM.createPortal(
Бул сиздин ачылуучу мазмунуңуздун ата-эненин артына жашырылбагандыгын камсыздайт, атүгүл ата-эне толуп кетсе: жашыруун же төмөнкү z-индекс. Биз буга чейин караган “Кыскартылган куралдардын кеңеши” сценарийинде мен порталды колдонуп, аспаптын кеңешин толуп кетүүдөн куткаруу үчүн колдондум: жашырылган клипти документтин корпусуна салып, контейнердин ичиндеги триггердин үстүнө жайгаштыруу. 3-калем сценарийин караңыз: Шойомбо Габриэль Айомиде тарабынан кесилген инструмент (Чечим) [айрылуу]. Терс таасирлери жок Stacking контекстти киргизүү Мурунку бөлүмдө түшүндүрүлгөн бардык ыкмалар көйгөйлүү стектөө контексттеринен элементтерди "чыгарууга" багытталган, бирок кээ бир жагдайлар бар, анда сиз чындыгында стекердик контекстти түзүүнү каалайсыз. Жаңы контекстти түзүү оңой, бирок бардык ыкмалар терс таасирлери менен коштолот. Башкача айтканда, изоляцияны колдонуудан башкасы: изоляция. Элементке колдонулганда, ал элементтин балдарынын стектөө контексти анын сыртындагы элементтердин таасири астында эмес, ар бир балага жана ошол контексттин ичинде аныкталат. Классикалык мисал бул элементке терс маанини ыйгаруу, мисалы z-индекс: -1. Элестетиңиз, сизде .card компоненти бар. Сиз .card'тын текстинин артында, бирок картанын фонунун үстүндө турган кооздук форманы кошкуңуз келет. Карточкада стекинг контексти жок, z-индекс: -1 форманы түпкү сток контекстинин ылдый жагына жөнөтөт (бүткүл бет). Бул аны .card'тын ак фонунун артында жок кылат: Шойомбо Габриэл Айомиде тарабынан жазылган Pen Negative z-индексин (проблема) караңыз. Муну чечүү үчүн биз изоляцияны жарыялайбыз: isolate on the parent .card: Караңыз Pen Negative z-индекс (чечим) [айрылуу] Шойомбо Габриэл Айомиде. Эми, .card элементинин өзү стекке контекстке айланат. Анын кошумча элементи - :before псевдо-элементте түзүлгөн декоративдик форма - z-индекске ээ болгондо: -1, ал ата-эненин стекке контекстинин эң түбүнө барат. Ал максаттуу түрдө тексттин артында жана картанын фонунун үстүндө эң сонун отурат. Корутунду Эсиңизде болсун: кийинки жолу сиздин z-индексиңиз көзөмөлдөн чыгып калгандай сезилгенде, бул контекстке камалып калат. Шилтемелер
Stacking context (MDN) Z-индекс жана стекинг контексттери (web.dev) Натали Пина "CSS'те изоляция касиети менен жаңы стакациялык контекстти кантип түзүү керек", "Эмне, z-индекс?", Джош Комо
SmashingMag боюнча кошумча окуу
"Чоң долбоорлордо CSS Z-индексин башкаруу", Стивен Фрисон "Жабышкак баштар жана толук бийиктиктеги элементтер: татаал айкалышы", Филип Браунен “Компонентке негизделген веб-тиркемеде Z-индексти башкаруу”, Павел Померанцев "Z-Index CSS касиети: Комплекстүү көрүнүш", Луи Лазарис