La scenaro preskaŭ ĉiam estas la sama, kiu estas datumtabelo ene de rulebla ujo. Ĉiu vico havas agadmenuon, malgrandan falmenuon kun iuj opcioj, kiel Redakti, Dupliki kaj Forigi. Vi konstruas ĝin, ĝi ŝajnas funkcii perfekte izole, kaj tiam iu metas ĝin ene de tiu rulebla div kaj aferoj disfalas. Mi vidis ĉi tiun precizan cimon en tri malsamaj kodbazoj: la ujo, la stako kaj la kadro, ĉiuj malsamaj. La cimo, tamen, estas tute identa. La falmenuo estas tranĉita ĉe la rando de la ujo. Aŭ ĝi aperas malantaŭ enhavo, kiu logike devus esti sub ĝi. Aŭ ĝi funkcias bone ĝis la uzanto ruliĝas, kaj tiam ĝi drivas. Vi atingas z-indekson: 9999. Kelkfoje ĝi helpas, sed alifoje ĝi faras absolute nenion. Tiu nekonsekvenco estas la unua indico, ke io pli profunda okazas. La kialo, ke ĝi daŭre revenas, estas ke tri apartaj retumsistemoj estas implikitaj, kaj la plej multaj programistoj komprenas ĉiun memstare sed neniam pensas pri kio okazas kiam ĉiuj tri kolizias: superfluo, stakigado de kuntekstoj kaj enhavado de blokoj.
Post kiam vi komprenas kiel ĉiuj tri interagas, la malsukcesaj reĝimoj ĉesas sentiĝi hazardaj. Fakte, ili fariĝas antaŭvideblaj. La Tri Aferoj Efektive Kaŭzantaj Ĉi tion Ni rigardu ĉiun el tiuj eroj detale. La Troflua Problemo Kiam vi agordas superfluon: kaŝitan, superfluon: rulumon aŭ superfluon: aŭtomate sur elementon, la retumilo tranĉos ĉion, kio etendiĝas preter ĝiaj limoj, inkluzive de absolute poziciigitaj posteuloj. .scroll-ujo { superfluo: auto; alteco: 300px; /* Ĉi tio tranĉos la falmenuon, punkton */ }
.dropdown { pozicio: absoluta; /* Ne gravas -- ankoraŭ tranĉita per .scroll-container */ }
Tio surprizis min la unuan fojon, kiam mi renkontis ĝin. Mi supozis pozicion: absoluta lasus elementon eskapi la tondadon de ujo. Ĝi ne faras. Praktike, tio signifas, ke absolute poziciigita menuo povas esti fortranĉita de iu ajn praulo, kiu havas nevideblan superfluan valoron, eĉ se tiu praulo ne estas la entenanta bloko de la menuo. Tondado kaj poziciigado estas apartaj sistemoj. Ili simple kolizias en manieroj kiuj aspektas tute hazardaj ĝis vi komprenas ambaŭ.
Jen ekzemplo de React uzante createPortal:
importi { createPortal } el 'react-dom'; import { useState, useEffect, useRef } el 'reagi';
funkcio Dropdown ({ anchorRef, isOpen, infanoj }) { const [position, setPosition] = uzuStato({ supro: 0, maldekstre: 0});
uziEfekton (() => { if (estasMalfermita && ankroRef.kurenta) { const rect = anchorRef.current.getBoundingClientRect (); starPozicio({ supro: rect.bottom + window.scrollY, maldekstre: rect.left + window.scrollX, }); } }, [isOpen, anchorRef]);
if (!isOpen) redonu nulo;
reveni krei Portalon(
, dokumento.korpo ); }Kaj, kompreneble, ni ne povas ignori alireblecon. Fiksaj elementoj, kiuj aperas super enhavo, ankoraŭ devas esti klavar-atingeblaj. Se la fokusa ordo nature ne moviĝas en la fiksan falmenuon, vi devos administri ĝin per kodo. Ankaŭ indas kontroli, ke ĝi ne sidas super alia interaga enhavo sen maniero forĵeti ĝin. Tiu mordas vin en klavartestado. CSS Ankora Pozicio: Kie mi pensas, ke ĉi tio direktiĝas CSS Anchor Positioning estas la direkto pri kiu mi plej interesas nun. Mi ne estis certa kiom multe de la spec estis efektive uzebla kiam mi unue rigardis ĝin. Ĝi permesas vin deklari la rilaton inter falmenuo kaj ĝia ellasilo rekte en CSS, kaj la retumilo pritraktas la koordinatojn. .trigger { ankro-nomo: --mia-trigger; }
.falmenuo { pozicio: absoluta; pozicio-ankro: --my-trigger; supro: ankro(malsupro); maldekstre: ankro(maldekstre); position-try-fallbacks: flip-bloko, flip-inline; }
La posedaĵo de pozicio-provo-falbacks estas tio, kio indas uzi ĉi tion per mana kalkulo. La retumilo provas alternativajn lokigojn antaŭ ol rezigni, do falmenuo ĉe la fundo de la vidfenestro aŭtomate renversiĝas supren anstataŭ esti fortranĉita. Retumila subteno estas solida en Chromium-bazitaj retumiloj kaj kreskas en Safaro. Fajrovulpo bezonas poliplenigaĵon. La pako @oddbird/css-anchor-positioning kovras la kernan specifon. Mi trafis kun ĝi aranĝajn randajn kazojn, kiuj postulis kompensojn, kiujn mi ne antaŭvidis, do traktu ĝin kiel progreseman plibonigon aŭ parigu ĝin kunJavaskripto-rezervo por Fajrovulpo. Resume, promesplena sed ankoraŭ ne universala. Testu en viaj celaj retumiloj. Kaj koncerne alireblecon, deklari vidan rilaton en CSS nenion diras al la alirebleco. aria-controls, aria-expanded, aria-haspopup — tiu parto ankoraŭ estas sur vi. Kelkfoje La Riparo Nur Movas La Elementon Antaŭ ol atingi portalon aŭ fari koordinatajn kalkulojn, mi ĉiam unue faras unu demandon: Ĉu ĉi tiu menuo efektive bezonas vivi ene de la rulujo? Se ĝi ne faras, movi la markadon al pli alta nivelo envolvaĵo forigas la problemon tute, sen JavaScript kaj neniuj koordinataj kalkuloj. Ĉi tio ne ĉiam eblas. Se la butono kaj falmenuo estas enkapsuligitaj en la sama komponento, movi unu sen la alia signifas repripensi la tutan API. Sed kiam vi povas fari ĝin, estas nenio por elpurigi. La problemo simple ne ekzistas. Kion Moderna CSS Ankoraŭ Ne Solvas CSS faris longan vojon ĉi tie, sed ankoraŭ estas lokoj, kie ĝi lasas vin. La pozicio: fiksitaj kaj transformaj problemoj ankoraŭ ekzistas. Ĝi estas intence en la specifo, kio signifas, ke neniu CSS-solvado ekzistas. Se vi uzas animacian bibliotekon, kiu envolvas vian aranĝon en transformita elemento, vi denove bezonas portalojn aŭ ankropozicion. CSS Anchor Positioning estas promesplena, sed nova. Kiel menciite antaŭe, Fajrovulpo ankoraŭ bezonas poliplenigaĵon en la momento, kiam mi skribas ĉi tion. Mi trafis aranĝajn randajn kazojn per ĝi, kiuj postulis falbacks, kiujn mi ne antaŭvidis. Se vi bezonas konsekvencan konduton tra ĉiuj retumiloj hodiaŭ, vi ankoraŭ serĉas JavaScript por la malfacilaj partoj. La aldono, por kiu mi efektive ŝanĝis mian laborfluon, estas la HTML Popover API, nun havebla en ĉiuj modernaj retumiloj. Elementoj kun la popover-atributo bildiĝas en la supra tavolo de la retumilo, super ĉio, sen JavaScript-poziciigo necesa.
Eskap-traktado, forĵeto-sur-klako-ekstere, kaj solida alirebleco-semantiko venas senpage por aferoj kiel konsiletoj, malkaŝaj fenestraĵoj kaj simplaj supermetaĵoj. Ĝi estas la unua ilo, kiun mi atingas nuntempe. Dirite, ĝi ne solvas poziciigon. Ĝi solvas tavoligon. Vi ankoraŭ bezonas ankropozicion aŭ JavaScript por vicigi popover al ĝia ellasilo. La Popover API pritraktas la tavoligon. Ankro-poziciigo pritraktas la allokigon. Kunigitaj, ili kovras la plej grandan parton de tio, kion vi antaŭe atingus por ke biblioteko faru. Decida Gvidilo Por Via Situacio Travivinte ĉion ĉi malfacile, jen kiel mi efektive pensas pri la elekto nun.
Uzu portalon. Mi uzus ĉi tion kiam la ellasilo loĝas profunde en nestitaj rulujoj. Mi uzis ĉi tiun ŝablonon por tabloj agaj menuoj kaj parigis ĝin kun fokusaj restarigo kaj alirebleco-kontroloj. Ĝi estas la plej fidinda opcio, sed buĝeta tempo por la kroma kablado. Uzu fiksan pozicion. Ĉi tio estas por kiam vi estas en vanila JavaScript aŭ malpeza kadro kaj povas kontroli, ke neniu praulo aplikas transformojn aŭ filtrilojn. Ĝi estas simpla por agordi kaj simpla por sencimi, kondiĉe ke tiu unu limo tenas. Uzu CSS Anchor Positioning. Atingu ĉi tion kiam via retumila subteno permesas ĝin. Se Firefox-subteno estas bezonata, parigu ĝin kun la @oddbird polyfill. Ĉi tie finfine iras la platformo kaj poste fariĝos via aliro. Restrukturu la DOM. Uzu ĉi tion kiam la arkitekturo permesas ĝin, kaj vi volas nulan rultempan kompleksecon. Mi kredas, ke ĝi estas verŝajne la plej subtaksita opcio. Kombinu ŝablonojn. Faru ĉi tion kiam vi volas ankro-poziciigon kiel vian ĉefan aliron, parigitan kun JavaScript-retumilo por nesubtenataj retumiloj. Aŭ portalo por DOM-lokigo parigita kun getBoundingClientRect () por koordinata precizeco.
Konkludo Mi kutimis trakti ĉi tiun cimon kiel unufojan aferon — ion por fliki kaj pluiri. Sed post kiam mi sidis kun ĝi sufiĉe longe por kompreni ĉiujn tri sistemojn engaĝitajn - superflua tondado, stakigado de kuntekstoj kaj enhavado de blokoj - ĝi ĉesis sentiĝi hazarda. Mi povis rigardi rompitan falmenuon kaj tuj spuri, kiu praulo respondecis. Tiu ŝanĝo en kiel mi legis la DOM estis la vera elportado. Ne ekzistas ununura ĝusta respondo. Kion mi atingis dependis de tio, kion mi povis kontroli en la kodbazo: portaloj, kiam la praarbo estis neantaŭvidebla; fiksa pozicio kiam ĝi estis pura kaj simpla; movi la elementon kiam nenio haltis min; kaj ankropozicio nun,kie mi povas. Kion ajn vi finfine elektas, ne traktu alireblecon kiel la lastan paŝon. Laŭ mia sperto, ĝuste tio estas preterlasita. La ARIA-rilatoj, la fokusa administrado, la klavara konduto - tiuj ne estas poluraj. Ili estas parto de tio, kio igas la aferon efektive funkcii. Rigardu la plenan fontkodon en mia GitHub-deponejo. Plia Legado Ĉi tiuj estas la referencoj, al kiuj mi daŭre revenis dum mi prilaboras ĉi tion:
La Stakiga Kunteksto (MDN) "CSS Anchor Positioning Guide", Juan Diego Rodriguez "Komenci kun La Popover API", Godstime Aburu Flosanta UI (floating-ui.com) CSS Superfluo (MDN)
