A lebegő menük, súgók és „további műveletek” panelek sok felületen ugyanabba a zsákutcába futnak: a komponens szülője overflow: hidden-t, transform-ot vagy új stacking contextet kapott, ezért a gondosan feltekert z-index: 99999 sem menti meg. A Popover API erre nem egy újabb pozicionáló segédkönyvtár, hanem böngészőszintű réteget ad.
A z-indexnek van plafonja
A z-index nem egy globális sorszám. Egy stacking contexten belül rendez; ha egy szülő új kontextust hoz létre, a gyereke nem ugorhat át a szülő testvérének rétege fölé. Ilyet többek között pozicionált, nem auto z-index, opacity, transform, filter és contain: paint is létrehoz. Innen ered a klasszikus hiba: a kártya saját menüje a szomszédos sticky fejléc mögé kerül, pedig papíron nagyobb a z-index.
A böngésző top layer rétege nem része ennek a versenynek: a dokumentum többi tartalma fölött van, és minden benne lévő elem saját stacking contextet alkot. Ide kerül például egy modálisan megnyitott dialog, a fullscreen elem és a popover is. Ezért a top layerbe tett panelt nem vágja le egy őse sem; nem kell az alkalmazás DOM-jának végére portálozni csak a megjelenítés miatt.
Két attribútum, használható alap
Egy alap műveletmenühöz JavaScript sem kell. A popovertarget invokerként összeköti a gombot a célelemmel; a böngésző kezeli a nyitást, a bezárást és a kapcsolódó ARIA-állapotot.
Az auto a jó kiindulópont egy menühöz vagy rövid információs panelhez. Az ilyen popover light-dismiss viselkedésű: kattintás a panelen kívül vagy Esc bezárhatja. A manual állapot nem záródik be így; erre való például egy nem modális értesítési panel, amelynek bezárását az alkalmazás maga kezeli. A kétféle viselkedés választása nem CSS-részlet, hanem interakciós döntés.
Programból ugyanaz az elem a showPopover(), hidePopover() és togglePopover() metódusokkal vezérelhető. Ez hasznos akkor, ha a nyitást mentés, aszinkron eredmény vagy egyedi billentyűparancs indítja, de a DOM és az akadálymentes alapmechanika maradhat natív.
Popover nem dialog
A top layer közös, a szemantika nem. A popover nem teszi inaktívvá a mögötte lévő dokumentumot és nem kényszerít fókuszt magára. Ha a felhasználónak egy döntést kell meghoznia, és addig nem dolgozhat a háttérben, a dialog.showModal() a megfelelő primitív: modalitást, fókuszkezelést és háttér-inertséget ad. Egy popover-ből csak azért dialogot csinálni, mert „felül kell lennie”, félrevezető billentyűzetes viselkedést eredményez.
Fordítva is igaz: egy lenyíló menü vagy formmezőhöz tartozó segédszöveg nem modal. Popoverrel a felhasználó továbbra is kattinthat, görgethet és dolgozhat a lapon. Ha azonban a panel valódi menü, a nyitás után is érdemes tudatosan kezelni a fókuszt, a nyílbillentyűket és a menüelemek szerepét; a top layer a rétegproblémát oldja meg, nem helyettesíti a teljes komponens viselkedését.
Stílus és pozíció: két külön feladat
A megnyitott állapotot a :popover-open pszeudoosztállyal lehet stílusozni. Itt jön egy fontos korlát: a Popover API a rétegezést és a bezárási szabályokat adja, nem azt, hogy a panel pontosan a gomb bal alsó sarkához tapadjon. Egyszerű elhelyezéshez marad a CSS pozicionálás; összetettebb, viewportszélhez igazodó „flip” és „shift” viselkedéshez továbbra is kell saját logika vagy egy erre épített komponens.
Top layerbeli elemhez ::backdrop is tartozhat. Ettől még egy popovernek általában nem kell elsötétített háttér: az a modal dialog vizuális jelzése. A popover látványát inkább a környezethez illő keret, árnyék, maximális szélesség és kis képernyőn biztonságos margó teszi használhatóvá.
Mikor éri meg?
Beállításmenü, „további műveletek” gomb, rövid magyarázat, dátummezőhöz kapcsolódó segédpanel: ezekhez a Popover API sok kézzel írt eseményfigyelőt és z-index-egyeztetést kivált. Feature detectionhez elég például a "showPopover" in HTMLElement.prototype ellenőrzés, és ahol nem érhető el, megtartható a meglévő, rejtett paneles vagy dialogos fallback. A specifikáció popover fejezete azt is jól mutatja, hogy ez nem egyetlen CSS-trükk, hanem a dokumentum interakciós modelljének része.
A gyakorlati tanulság egyszerű: ha a gond az, hogy valaminek tényleg a teljes alkalmazás fölött kell megjelennie, először azt döntsd el, modal párbeszédablak-e vagy nem modális lebegő felület. Utána a megfelelő natív elem leveszi a válladról a rétegkezelés egy jelentős részét — de a fókuszt, a szemantikát és a pontos geometriát továbbra is a komponens igényeihez kell igazítani.