Atburðarásin er nánast alltaf sú sama, sem er gagnatafla inni í skrunanlegum íláti. Hver röð er með aðgerðavalmynd, lítill fellilisti með nokkrum valkostum, eins og Breyta, Afrita og Eyða. Þú smíðar það, það virðist virka fullkomlega í einangrun, og svo setur einhver það inn í það scrollable div og hlutirnir falla í sundur. Ég hef séð nákvæmlega þessa villu í þremur mismunandi kóðagrunnum: ílátinu, staflanum og rammanum, allt öðruvísi. Gallinn er þó algjörlega eins. Fellilistinn er klipptur við brún ílátsins. Eða það birtist á bak við efni sem ætti rökrétt að vera fyrir neðan það. Eða það virkar fínt þar til notandinn flettir, og þá rekur hann. Þú nærð í z-vísitölu: 9999. Stundum hjálpar það, en stundum gerir það nákvæmlega ekkert. Það ósamræmi er fyrsta vísbendingin um að eitthvað dýpra sé að gerast. Ástæðan fyrir því að það kemur sífellt aftur er að þrjú aðskilin vafrakerfi eiga í hlut og flestir forritarar skilja hvert og eitt fyrir sig en hugsa aldrei um hvað gerist þegar allir þrír rekast á: flæða, stafla samhengi og innihalda blokkir.
Þegar þú skilur hvernig allir þrír hafa samskipti, hættir bilunarstillingunum að finnast tilviljunarkenndar. Í raun verða þeir fyrirsjáanlegir. Þrír hlutir sem í raun valda þessu Við skulum skoða hvert þessara atriða í smáatriðum. Yfirfallsvandamálið Þegar þú stillir yfirflæði: falið, yfirflæði: fletta eða yfirflæði: sjálfvirkt á frumefni, mun vafrinn klippa allt sem nær út fyrir mörk þess, þar með talið afkomendur sem eru nákvæmlega staðsettir. .scroll-container { flæða: sjálfvirkt; hæð: 300px; /* Þetta mun klippa niður fellilistann, punktur */ }
.dropdown { staða: alger; /* Skiptir ekki máli -- enn klippt af .scroll-container */ }
Það kom mér á óvart í fyrsta skipti sem ég lenti í því. Ég hafði tekið mér stöðu: alger myndi láta frumefni sleppa við úrklippingu gáms. Það gerir það ekki. Í reynd þýðir það að hvaða forföður sem er sem hefur ósýnilegt yfirfallsgildi getur verið skorið úr algerlega staðsettri valmynd, jafnvel þó að forfaðirinn sé ekki kubb valmyndarinnar. Klipping og staðsetning eru aðskilin kerfi. Þeir lenda bara í árekstri á þann hátt sem lítur út fyrir að vera algjörlega tilviljunarkenndur þar til þú skilur bæði.
Hér er React dæmi með því að nota createPortal:
flytja inn { createPortal } frá 'react-dom'; flytja inn { useState, useEffect, useRef } úr 'react';
fallvalmynd({ anchorRef, isOpen, börn }) { const [staða, setPosition] = useState({ efst: 0, vinstri: 0 });
useEffect(() => { if (erOpen && anchorRef.current) { const rect = anchorRef.current.getBoundingClientRect(); setPosition({ efst: rect.bottom + window.scrollY, vinstri: rect.left + window.scrollX, }); } }, [isOpen, anchorRef]);
ef (!isOpen) skila núll;
skilaðu createPortal(
Og auðvitað getum við ekki hunsað aðgengi. Fastir þættir sem birtast yfir efni verða samt að vera hægt að nálgast á lyklaborðinu. Ef fókusröðin færist ekki náttúrulega inn í fasta fellilistann þarftu að stjórna henni með kóða. Það er líka þess virði að athuga að það situr ekki yfir öðru gagnvirku efni án þess að hægt sé að hafna því. Þessi bítur þig í lyklaborðsprófunum. CSS akkerisstaða: Hvert ég held að þetta stefni CSS akkerisstaða er sú stefna sem ég hef mestan áhuga á núna. Ég var ekki viss um hversu mikið af forskriftinni var í raun nothæft þegar ég horfði á það fyrst. Það gerir þér kleift að lýsa sambandinu milli fellilista og kveikju hans beint í CSS og vafrinn sér um hnitin. .trigger { akkerisnafn: --my-trigger; }
.valmynd { staða: alger; stöðu-akkeri: --my-trigger; efst: akkeri(neðst); vinstri: akkeri(vinstri); stöðu-reyna-fallbacks: flip-block, flip-inline; }
Staða-reyna-fallback eignin er það sem gerir þetta þess virði að nota það yfir handvirkan útreikning. Vafrinn reynir aðrar staðsetningar áður en hann gefst upp, þannig að fellilisti neðst á útsýnisglugganum snýr sjálfkrafa upp í stað þess að klippast af. Vafrastuðningur er traustur í vöfrum sem byggir á Chromium og fer vaxandi í Safari. Firefox þarf polyfill. @oddbird/css-anchor-positioning pakkinn nær yfir kjarnaforskriftina. Ég hef lent í útlitsbrún tilfellum með því sem kröfðust fallbacks sem ég bjóst ekki við, svo meðhöndlaðu það sem framsækna viðbót eða paraðu það viðJavaScript fallback fyrir Firefox. Í stuttu máli, efnilegur en ekki algilt ennþá. Prófaðu í markvöfrum þínum. Og hvað aðgengi varðar segir það aðgengistrénu ekki neitt að lýsa yfir sjónrænu sambandi í CSS. aríu-stýringar, aríu-útvíkkað, aríu-haspopup - þessi hluti er enn á þér. Stundum er lagfæringin bara að færa þáttinn Áður en ég næ í gátt eða geri hnitaútreikninga spyr ég alltaf einnar spurningar fyrst: Þarf þessi fellilisti í raun og veru að vera inni í flettigámnum? Ef það gerir það ekki, með því að færa merkinguna yfir á hærra stigi umbúðir, útrýma vandanum algjörlega, án JavaScript og enga samræmda útreikninga. Þetta er ekki alltaf hægt. Ef hnappurinn og fellivalmyndin eru hjúpuð í sama íhlutinn þýðir að færa einn án hins þýðir að endurhugsa allt API. En þegar þú getur gert það, þá er ekkert að kemba. Vandamálið er bara ekki til. Það sem nútíma CSS leysir samt ekki CSS hefur náð langt hér, en það eru enn staðir þar sem það svíkur þig. Staðan: fast og umbreytt mál eru enn til staðar. Það er viljandi í forskriftinni, sem þýðir að engin CSS lausn er til. Ef þú ert að nota hreyfimyndasafn sem vefur skipulagið þitt í umbreyttan þátt, þá ertu aftur að þurfa gáttir eða akkerisstaðsetningu. CSS akkerisstaða er efnileg, en ný. Eins og fyrr segir þarf Firefox enn fjölfyllingu á þeim tíma sem ég er að skrifa þetta. Ég hef lent í útlitsbrúntilfellum með því sem kröfðust fallbacks sem ég bjóst ekki við. Ef þú þarft samræmda hegðun í öllum vöfrum í dag, ertu enn að ná í JavaScript fyrir erfiðu hlutana. Viðbótin sem ég hef í raun breytt verkflæðinu mínu fyrir er HTML Popover API, nú fáanlegt í öllum nútíma vöfrum. Þættir með popover eiginleikann birtast í efsta lagi vafrans, fyrir ofan allt, án þess að JavaScript sé þörf á staðsetningu.
Escape-meðhöndlun, sleppa-við-smell-úti og traust merkingarfræði aðgengis koma ókeypis fyrir hluti eins og verkfæraábendingar, upplýsingagræjur og einfaldar yfirlögn. Það er fyrsta tólið sem ég næ í núna. Sem sagt, það leysir ekki staðsetningu. Það leysir lagskiptingu. Þú þarft samt akkerisstaðsetningu eða JavaScript til að stilla sprettiglugga við kveikjuna. Popover API sér um lagskiptinguna. Akkerisstaða sér um staðsetninguna. Þegar þeir eru notaðir saman ná þeir yfir flest það sem þú hafðir áður náð fyrir bókasafn til að gera. Ákvörðunarleiðbeiningar fyrir þínar aðstæður Eftir að hafa farið í gegnum allt þetta á erfiðan hátt, svona hugsa ég um valið núna.
Notaðu gátt. Ég myndi nota þetta þegar kveikjan býr djúpt í hreiðrum skrúfílátum. Ég notaði þetta mynstur fyrir borðaðgerðavalmyndir og paraði það við endurheimt fókus og aðgengisskoðun. Það er áreiðanlegasti valkosturinn, en fjárhagsáætlun tími fyrir auka raflögn. Notaðu fasta staðsetningu. Þetta er fyrir þegar þú ert í vanillu JavaScript eða léttum ramma og getur staðfest að enginn forfaðir noti umbreytingar eða síur. Það er einfalt í uppsetningu og einfalt að kemba, svo lengi sem þessi eina þvingun heldur. Notaðu CSS Anchor Positioning.Reach fyrir þetta þegar vafrastuðningur þinn leyfir það. Ef þörf er á Firefox stuðningi skaltu para hann við @oddbird fjölfyllinguna. Þetta er þangað sem vettvangurinn stefnir að lokum og mun að lokum verða þín nálgun. Endurskipuleggja DOM. Notaðu þetta þegar arkitektúrinn leyfir það og þú vilt núll flókið keyrslutíma. Ég tel að það sé líklega vanmetnasti kosturinn. Sameina mynstur. Gerðu þetta þegar þú vilt staðsetja akkeri sem aðalaðferð þína, parað með JavaScript varakerfi fyrir óstudda vafra. Eða gátt fyrir DOM staðsetningu parað við getBoundingClientRect() fyrir nákvæmni hnit.
Niðurstaða Ég var vanur að meðhöndla þessa villu sem einstakt mál - eitthvað til að laga og halda áfram frá. En þegar ég sat með það nógu lengi til að skilja öll þrjú kerfin sem taka þátt - yfirfallsklipping, stöflun samhengi og innihalda kubba - hætti það að finnast það af handahófi. Ég gat horft á brotna fellilista og rakið strax hvaða forfaðir var ábyrgur. Þessi breyting á því hvernig ég las DOM var hið raunverulega afgreiðsla. Það er ekkert eitt rétt svar. Það sem ég náði í var háð því hvað ég gat stjórnað í kóðagrunninum: gáttir þegar forfeðurtréð var óútreiknanlegt; föst staðsetning þegar það var hreint og einfalt; hreyfa þáttinn þegar ekkert var að stoppa mig; og staðsetning akkeris núna,þar sem ég get. Hvað sem þú endar með að velja skaltu ekki líta á aðgengi sem síðasta skrefið. Í minni reynslu er það einmitt þegar því er sleppt. ARIA samböndin, fókusstjórnunin, lyklaborðshegðunin - þau eru ekki pólsk. Þeir eru hluti af því sem gerir hlutinn í raun að virka. Skoðaðu allan frumkóðann í GitHub versluninni minni. Frekari lestur Þetta eru tilvísanir sem ég kom alltaf aftur til þegar ég vann í gegnum þetta:
The Stacking Context (MDN) „CSS akkerisstaðsetningarhandbók“, Juan Diego Rodriguez „Að byrja með Popover API“, Godstime Aburu Fljótandi notendaviðmót (floating-ui.com) CSS yfirfall (MDN)
