Сценари нь бараг үргэлж ижил байдаг бөгөөд энэ нь гүйлгэх боломжтой контейнер доторх өгөгдлийн хүснэгт юм. Мөр бүр нь үйлдлийн цэстэй, Засварлах, Хуулбарлах, Устгах гэх мэт сонголттой жижиг унадаг цэстэй. Та үүнийг бүтээнэ, энэ нь тусад нь төгс ажилладаг юм шиг санагддаг, дараа нь хэн нэгэн үүнийг гүйлгэх боломжтой див дотор байрлуулж, бүх зүйл нурж унах болно. Би энэ алдааг гурван өөр кодын санд харсан: контейнер, стек, хүрээ гэх мэт бүгд өөр. Гэсэн хэдий ч алдаа нь бүхэлдээ ижил байна. Унждаг зүйл нь савны ирмэг дээр тайрагдана. Эсвэл логикийн хувьд доор байх ёстой агуулгын ард гарч ирдэг. Эсвэл хэрэглэгч гүйлгэх хүртэл зүгээр ажиллаад дараа нь эргэлддэг. Та z-индекс: 9999-д хүрдэг. Заримдаа энэ нь тусалдаг, гэхдээ бусад үед энэ нь огтхон ч хамаагүй. Энэ үл нийцэл нь илүү гүнзгий зүйл болж байгааг илтгэх анхны дохио юм. Энэ нь дахин гарч ирдэг шалтгаан нь гурван тусдаа хөтчийн системтэй холбоотой бөгөөд ихэнх хөгжүүлэгчид тус бүрийг тусад нь ойлгодог боловч гурвуулаа мөргөлдөх үед юу болох талаар хэзээ ч боддоггүй: халих, хавсаргах контекст, блокуудыг агуулсан.
Гурвуулаа хэрхэн харилцан үйлчилдгийг ойлгосны дараа бүтэлгүйтлийн горим санамсаргүй байдлаар мэдрэгдэхээ болино. Үнэндээ тэд урьдчилан таамаглах боломжтой болдог. Үнэндээ үүнийг үүсгэсэн гурван зүйл Эдгээр зүйл бүрийг нарийвчлан авч үзье. Халих асуудал Элемент дээр overflow: hidden, overflow: гүйлгэх, эсвэл overflow: auto гэсэн тохиргоог хийх үед хөтөч өөрийн хязгаараас хэтэрсэн бүх зүйлийг, түүний дотор туйлын байрлалтай удамшлыг хайчлах болно. .scroll-container { халих: автомат; өндөр: 300px; /* Энэ нь унадаг цэсийг таслах болно, цэг */ }
.dropdown { байрлал: үнэмлэхүй; /* хамаагүй -- .scroll-container-ээр таслагдсан хэвээр */ }
Энэ нь намайг анх тааралдахад гайхсан. Би байр сууриа олж авсан: үнэмлэхүй нь элементийг савны зүсэлтээс зугтахыг зөвшөөрдөг. Тэгэхгүй. Практикт энэ нь туйлын байрлалтай цэсийг үл үзэгдэх халих утгатай аль ч өвөг дээдэс тасалж болно гэсэн үг, тэр өвөг нь цэсийн блок биш байсан ч гэсэн. Таслах, байрлуулах нь тусдаа систем юм. Та хоёуланг нь ойлгох хүртэл тэд санамсаргүй байдлаар мөргөлддөг.
CreatePortal ашиглан хариу үйлдэл үзүүлэх жишээ энд байна:
'react-dom'-оос { createPortal }-г импортлох; 'react'-аас { useState, useEffect, useRef} импортлох;
функц Dropdown({anchorRef, isOpen, хүүхдүүд }) { const [байршил, setPosition] = useState ({ дээд: 0, зүүн: 0 });
useEffect(() => { хэрэв (isOpen && anchorRef.current) { const rect = anchorRef.current.getBoundingClientRect(); setPosition({ дээд: rect.bottom + window.scrollY, зүүн: rect.left + window.scrollX, }); } }, [isOpen, anchorRef]);
хэрэв (!isOpen) null буцаана;
createPortal буцаах(
Мэдээжийн хэрэг, бид хүртээмжийг үл тоомсорлож болохгүй. Контент дээр гарч ирэх тогтмол элементүүд нь гараар холбогдох боломжтой хэвээр байх ёстой. Хэрэв фокус дараалал нь тогтсон унадаг цэс рүү аяндаа шилжихгүй бол та код ашиглан үүнийг удирдах хэрэгтэй. Энэ нь бусад интерактив контент дээр суудаггүй эсэхийг шалгах нь зүйтэй бөгөөд үүнийг үгүйсгэх аргагүй юм. Энэ нь таныг гарны шалгалтанд хаздаг. CSS зангууны байрлал: Миний бодлоор энэ чиглэл CSS Anchor Positioning бол яг одоо миний хамгийн их сонирхож байгаа чиглэл юм. Би үүнийг анх харахад яг хэдэн үзүүлэлтийг ашиглах боломжтойг сайн мэдэхгүй байсан. Энэ нь унадаг цэс болон түүний триггер хоорондын хамаарлыг CSS дээр шууд зарлах боломжийг олгодог бөгөөд хөтөч нь координатуудыг зохицуулдаг. .триггер { зангууны нэр: --миний гох; }
.унадаг цэс { байрлал: үнэмлэхүй; position-anchor: --my-thrigger; дээд: зангуу (доод); зүүн: зангуу (зүүн); position-try-fallbacks: flip-block, flip-inline; }
Pozisyon-try-fallbacks шинж чанар нь үүнийг гараар тооцоололд ашиглахад үнэ цэнэтэй болгодог зүйл юм. Хөтөч бууж өгөхөөсөө өмнө өөр байршлуудыг туршиж үздэг тул харах цонхны доод хэсэгт байрлах уналт нь таслагдахын оронд автоматаар дээшээ эргэдэг. Хөтчийн дэмжлэг нь Chromium-д суурилсан хөтчүүдэд тогтвортой бөгөөд Safari-д улам бүр нэмэгдсээр байна. Firefox-д полифилл хэрэгтэй. @oddbird/css-anchor-positioning багц нь үндсэн үзүүлэлтүүдийг хамардаг. Би түүгээр миний төсөөлөөгүй буцаалт шаардсан layout edge кейсүүдийг давсан тул үүнийг дэвшилтэт сайжруулалт гэж үзэх эсвэлFirefox-д зориулсан JavaScript нөөц. Товчхондоо, ирээдүйтэй боловч бүх нийтийн хараахан биш. Зорилтот хөтөч дээрээ туршиж үзээрэй. Мөн хүртээмжтэй байдлын хувьд CSS-д харааны хамаарлыг зарлах нь хүртээмжийн модонд юу ч хэлэхгүй. aria-controls, aria-expanded, aria-haspopup - тэр хэсэг нь та нарын дээр хэвээр байна. Заримдаа засвар нь зүгээр л элементийг хөдөлгөдөг Портал руу очих эсвэл координатын тооцоо хийхээсээ өмнө би үргэлж нэг асуулт асуудаг: Энэ уналт нь гүйлгэх савны дотор байх ёстой юу? Үгүй бол тэмдэглэгээг дээд түвшний боодол руу шилжүүлэх нь JavaScript болон координатын тооцоололгүйгээр асуудлыг бүрэн арилгана. Энэ нь үргэлж боломжтой байдаггүй. Хэрэв товчлуур болон унадаг цэсийг нэг бүрэлдэхүүн хэсэгт багтаасан бол нэгийг нь нөгөөг нь оруулалгүйгээр шилжүүлэх нь API-г бүхэлд нь дахин бодож үзэх гэсэн үг юм. Гэхдээ та үүнийг хийж чадвал дибаг хийх зүйл байхгүй. Асуудал зүгээр л байхгүй. Орчин үеийн CSS юуг шийдэж чадахгүй байна вэ? CSS энд маш их замыг туулсан ч таныг урам хугарах газрууд байсаар байна. Байршил: засч залруулах, өөрчлөх асуудал байсаар байна. Энэ нь зориудаар тодорхойлогдсон байгаа бөгөөд энэ нь CSS тойрон гарах арга зам байхгүй гэсэн үг юм. Хэрэв та өөрийн байршлыг өөрчилсөн элементэд багтаасан хөдөлгөөнт номын санг ашиглаж байгаа бол танд портал эсвэл зангууны байрлал хэрэгтэй болно. CSS Anchor Positioning нь ирээдүйтэй боловч шинэ юм. Өмнө дурьдсанчлан, намайг үүнийг бичиж байх үед Firefox-д полифилл хэрэгтэй хэвээр байна. Би түүгээр миний төсөөлөөгүй буцаалт шаардсан layout edge кейсүүдийг давлаа. Хэрэв танд өнөөдөр бүх хөтчүүдэд тогтвортой ажиллах шаардлагатай бол та төвөгтэй хэсгүүдийн хувьд JavaScript-г хайж байна. Миний ажлын урсгалыг өөрчилсөн нэмэлт зүйл бол орчин үеийн бүх хөтөч дээр ашиглах боломжтой HTML Popover API юм. Popover шинж чанар бүхий элементүүдийг хөтчийн дээд давхаргад, бүх зүйл дээр байрлуулж, JavaScript-н байршлыг тогтоох шаардлагагүй.
Зааварчилгаанаас зугтах, гадаа товшилтоор хаах, хатуу хандалтын семантикууд нь зөвлөмж, тодруулга виджет, энгийн давхаргууд зэрэгт үнэ төлбөргүй ирдэг. Энэ бол миний одоо хүрч байгаа анхны хэрэгсэл юм. Энэ нь байршлыг шийдэхгүй гэж хэлсэн. Энэ нь давхаргыг шийддэг. Поповерыг триггертэй нь зэрэгцүүлэхийн тулд танд зангууны байршил эсвэл JavaScript хэрэгтэй хэвээр байна. Popover API нь давхаргыг зохицуулдаг. Зангууны байрлал нь байрлуулах ажлыг зохицуулдаг. Хамтдаа ашиглавал эдгээр нь таны өмнө нь номын санд хандаж байсан зүйлсийн ихэнхийг хамардаг. Таны нөхцөл байдлын талаар шийдвэр гаргах гарын авлага Энэ бүх хүнд хэцүү замыг туулсаны дараа би сонголтынхоо талаар хэрхэн бодож байгаагаа эндээс харж болно.
Портал ашиглана уу. Би үүнийг гох нь гүйлгэх савны гүнд байрлах үед ашиглах болно. Би энэ загварыг хүснэгтийн үйлдлийн цэсэнд ашиглаж, фокус сэргээх болон хүртээмжтэй байдлын шалгалттай хослуулсан. Энэ бол хамгийн найдвартай сонголт боловч нэмэлт утас тавихад зарцуулах цаг хугацаа юм. Тогтмол байрлалыг ашиглана уу. Энэ нь таныг ванилийн JavaScript эсвэл хөнгөн фрэймворк ашиглаж байгаа үед зориулагдсан бөгөөд ямар ч өвөг дээдэс хувиргалт, шүүлтүүр хэрэглэхгүй байхыг баталгаажуулах боломжгүй. Үүнийг тохируулахад хялбар, дибаг хийхэд хялбар бөгөөд зөвхөн нэг хязгаарлалтыг дагаж мөрддөг. Таны хөтөчийн дэмжлэг зөвшөөрвөл CSS Anchor Positioning.Reach-г ашиглана уу. Хэрэв Firefox-ын дэмжлэг шаардлагатай бол @oddbird polyfill-тэй хослуул. Энэ бол платформ эцэстээ чиглэж байгаа газар бөгөөд эцэст нь таны хэрэгжүүлэх арга зам болно. DOM-ийн бүтцийг өөрчлөөрэй. Архитектур зөвшөөрвөл үүнийг ашиглана уу, та ажиллах үеийн нарийн төвөгтэй байдал байхгүй байхыг хүсч байна. Энэ нь хамгийн дутуу үнэлэгдсэн сонголт гэдэгт би итгэдэг. Загваруудыг нэгтгэнэ үү. Дэмжигдээгүй хөтчүүдэд зориулсан JavaScript нөөцтэй хослуулан зангууны байршлыг үндсэн арга болгон ашиглахыг хүсвэл үүнийг хий. Эсвэл координатын нарийвчлалын үүднээс getBoundingClientRect()-тай хослуулсан DOM байршуулах портал.
Дүгнэлт Би энэ алдааг нэг удаагийн асуудал гэж үздэг байсан - засварлаж, үргэлжлүүлэх зүйл. Гэхдээ би үүнтэй холбоотой бүх гурван системийг ойлгоход хангалттай удаан суусны дараа - халих хайчилбар, контекст овоолго, блок агуулсан - энэ нь санамсаргүй мэт санагдахаа больсон. Би эвдэрсэн унадаг цэсийг хараад аль өвөг дээдсийнхээ хариуцлагыг шууд олж мэдэх боломжтой. Миний DOM-г хэрхэн уншихад хийсэн өөрчлөлт нь жинхэнэ утгаараа байсан. Ганц зөв хариулт байхгүй. Миний хүрэх зүйл нь кодын санд юу удирдаж чадахаас шалтгаална: өвөг модыг урьдчилан таамаглах боломжгүй байсан порталууд; цэвэр, энгийн үед тогтмол байрлал; намайг юу ч зогсоохгүй байхад элементийг хөдөлгөх; болон зангууны байрлалыг одоо,би хаана чадах вэ. Та юу ч сонгосон бай, хүртээмжийг эцсийн алхам гэж бүү үз. Миний туршлагаас харахад яг тэр үед алгасдаг. ARIA-ийн харилцаа, фокусын удирдлага, гарны үйлдэл - эдгээр нь өнгөлөгч биш юм. Эдгээр нь тухайн зүйлийг бодитой болгодог зүйлийн нэг хэсэг юм. Миний GitHub репо дээрээс бүрэн эх кодыг үзээрэй. Цааш унших Үүнийг хийж байх хугацаандаа миний эргэн ирсэн лавлагаа нь:
Стекийн контекст (MDN) Хуан Диего Родригес "CSS зангууны байршлын гарын авлага" "Popover API-г ашиглаж эхлэх нь", Godstime Aburu Хөвөгч UI (floating-ui.com) CSS Overflow (MDN)
