Сценарио је скоро увек исти, а то је табела података унутар контејнера који се може померати. Сваки ред има мени радњи, мали падајући мени са неким опцијама, као што су Едит, Дуплицате и Делете. Саградите га, чини се да савршено функционише у изолацији, а онда га неко стави у тај див који се може померати и ствари се распадају. Видео сам ову тачну грешку у три различите базе кода: контејнер, стек и оквир, сви различити. Грешка је, међутим, потпуно идентична. Падајући мени се исече на ивици контејнера. Или се појављује иза садржаја који би логично требало да буде испод њега. Или ради добро док корисник не скролује, а онда се помера. Посегнете за з-индексом: 9999. Понекад помаже, али други пут не ради апсолутно ништа. Та недоследност је први траг да се дешава нешто дубље. Разлог зашто се стално враћа је тај што су укључена три одвојена система претраживача, а већина програмера разуме сваки за себе, али никада не размишља о томе шта се дешава када се сва три сударе: преливање, слагање контекста и блокови који садрже.
Једном када схватите како сва три интерагују, режими квара престају да се осећају насумично. У ствари, они постају предвидљиви. Три ствари које заправо узрокују ово Погледајмо сваку од ових ставки детаљно. Проблем преливања Када поставите оверфлов: хидден, оверфлов: сцролл или оверфлов: ауто на елемент, прегледач ће исечити све што се протеже изван његових граница, укључујући апсолутно позициониране потомке. .сцролл-цонтаинер { оверфлов: ауто; висина: 300пк; /* Ово ће исећи падајући мени, тачка */ }
.дропдовн { позиција: апсолутна; /* Није важно -- и даље је исечен .сцролл-цонтаинер */ }
То ме је изненадило када сам први пут налетео на то. Претпоставио сам позицију: апсолутно би омогућило елементу да избегне исечак контејнера. није. У пракси, то значи да апсолутно позиционирани мени може да одсече било који предак који има невидљиву вредност преливања, чак и ако тај предак није блок који садржи мени. Клиповање и позиционирање су одвојени системи. Они се само случајно сударе на начине који изгледају потпуно насумично док не разумете обоје.
Ево Реацт примера користећи цреатеПортал:
импорт { цреатеПортал } из 'реацт-дом'; импорт { усеСтате, усеЕффецт, усеРеф } из 'реацт';
фунцтион Дропдовн({ анцхорРеф, исОпен, деца }) { цонст [позиција, сетПоситион] = усеСтате({ врх: 0, лево: 0 });
усеЕффецт(() => { иф (исОпен && анцхорРеф.цуррент) { цонст рецт = анцхорРеф.цуррент.гетБоундингЦлиентРецт(); сетПоситион({ горе: рецт.боттом + виндов.сцроллИ, лево: рецт.лефт + виндов.сцроллКс, }); } }, [исОпен, анцхорРеф]);
иф (!исОпен) врати нулл;
врати цреатеПортал( <див ид="падајући-демо" роле="мени" цлассНаме="падајући мени" стиле={{ поситион: 'апсолуте', топ: поситион.топ, лефт: поситион.лефт }} > {деца} , документ.тело ); }
И, наравно, не можемо занемарити приступачност. Фиксни елементи који се појављују изнад садржаја морају и даље бити доступни тастатуром. Ако се редослед фокуса природно не помера у фиксни падајући мени, мораћете да управљате њиме помоћу кода. Такође је вредно проверити да се не налази преко другог интерактивног садржаја без начина да га одбаците. Тај те угризе у тестирању тастатуре. Позиционирање ЦСС сидра: где мислим да ово иде ЦСС Анцхор Позиционирање је правац који ме тренутно највише занима. Нисам био сигуран колико је спецификација заправо употребљива када сам је први пут погледала. Омогућава вам да декларишете однос између падајућег менија и његовог окидача директно у ЦСС-у, а претраживач управља координатама. .триггер { анцхор-наме: --ми-триггер; }
.дропдовн-мену { позиција: апсолутна; поситион-анцхор: --ми-триггер; врх: сидро(доле); лево: сидро(лево); позиција-покушај-фаллбацкс: флип-блоцк, флип-инлине; }
Својство поситион-три-фаллбацкс је оно што ово чини вредним употребе у односу на ручно израчунавање. Прегледач покушава алтернативна одредишта пре него што одустане, тако да се падајући мени на дну оквира за приказ аутоматски окреће нагоре уместо да буде одсечен. Подршка за прегледач је солидна у прегледачима заснованим на Цхромиум-у и расте у Сафарију. Фирефок-у је потребан полифил. Пакет @оддбирд/цсс-анцхор-поситионинг покрива основне спецификације. Са њим сам погодио ивице распореда које захтевају резервне опције које нисам очекивао, па га третирајте као прогресивно побољшање или га упарите саЗамена за ЈаваСцрипт за Фирефок. Укратко, обећавајуће, али још увек не универзалне. Тестирајте у циљаним прегледачима. А што се приступачности тиче, декларисање визуелног односа у ЦСС-у ништа не говори стаблу приступачности. ариа-цонтролс, ариа-екпандед, ариа-хаспопуп — тај део је још увек на вама. Понекад је поправка само померање елемента Пре него што посегнем за порталом или извршим прорачуне координата, увек прво поставим једно питање: да ли овај падајући мени заиста треба да живи унутар контејнера за померање? Ако се то не деси, померање ознаке у омотач вишег нивоа у потпуности елиминише проблем, без ЈаваСцрипт-а и израчунавања координата. Ово није увек могуће. Ако су дугме и падајући мени инкапсулирани у истој компоненти, померање једног без другог значи преиспитивање целог АПИ-ја. Али када то можете да урадите, нема шта за отклањање грешака. Проблем једноставно не постоји. Оно што савремени ЦСС још увек не решава ЦСС је овде прешао дуг пут, али још увек има места на којима вас изневерава. Положај: поправљени проблеми и проблеми трансформације су и даље присутни. Намерно је у спецификацији, што значи да не постоји ЦСС решење. Ако користите библиотеку анимације која обавија ваш изглед у трансформисани елемент, вратили сте се потребним порталима или позиционирању сидра. ЦСС Анцхор Позиционирање је обећавајуће, али ново. Као што је раније поменуто, Фирефоку је још увек потребан полифил у време када ово пишем. Са њим сам погодио ивице распореда за које су биле потребне резерве које нисам очекивао. Ако вам је данас потребно доследно понашање у свим прегледачима, и даље посежете за ЈаваСцриптом за незгодне делове. Додатак за који сам заправо променио свој радни ток је ХТМЛ Поповер АПИ, који је сада доступан у свим модерним прегледачима. Елементи са атрибутом поповер се приказују у горњем слоју прегледача, изнад свега, без потребе за ЈаваСцрипт позиционирањем.
<буттон поповертаргет="дропдовн-демо">Отвори <див ид="дропдовн-демо" поповер="мануал" роле="мену">Садржај искачућих страница
Избегавање руковања, одбацивање на клик-напољу и солидна семантика приступачности су бесплатни за ствари као што су описи алата, виџети за откривање података и једноставна преклапања. То је први алат до којег долазим. Међутим, то не решава позиционирање. Решава слојевитост. И даље вам је потребно позиционирање сидра или ЈаваСцрипт да бисте поравнали искачући прозор са његовим окидачем. Поповер АПИ управља слојевима. Позиционирање сидра управља постављањем. Када се користе заједно, покривају већину онога што сте претходно посегнули за библиотеком. Водич за доношење одлука за вашу ситуацију Након што сам све ово прошао на тежи начин, ево како сада заправо размишљам о избору.
Користите портал. Користио бих ово када окидач живи дубоко у угнежђеним контејнерима за померање. Користио сам овај образац за меније радњи на табели и упарио га са враћањем фокуса и провером приступачности. То је најпоузданија опција, али буџетско време за додатно ожичење. Користите фиксно позиционирање. Ово је за када сте у ванилла ЈаваСцрипт-у или лаганом оквиру и можете да проверите да ниједан предак не примењује трансформације или филтере. Једноставан је за подешавање и једноставан за отклањање грешака, све док постоји једно ограничење. Користите ЦСС Анцхор Поситионинг. Посегните за ово када то дозволи подршка вашег претраживача. Ако је потребна подршка за Фирефок, упарите је са полифилом @оддбирд. Ту платформа на крају иде и на крају ће постати ваш приступ. Реструктурирајте ДОМ. Користите ово када архитектура то дозвољава и ако желите нулту сложеност времена извршавања. Верујем да је то вероватно најпотцењенија опција. Комбинујте обрасце. Урадите ово када желите позиционирање сидра као примарни приступ, упарено са резервним ЈаваСцрипт-ом за неподржане прегледаче. Или портал за ДОМ постављање упарен са гетБоундингЦлиентРецт() за тачност координата.
Закључак Некада сам ову грешку третирао као једнократни проблем — нешто за закрпање и од чега треба да се настави. Али када сам седео са њим довољно дуго да разумем сва три укључена система – пресецање преливања, слагање контекста и садржај блокова – престао је да се осећа насумично. Могао сам да погледам покварени падајући мени и одмах пронађем који је предак одговоран. Та промена у начину на који сам читао ДОМ била је прави закључак. Не постоји један тачан одговор. Оно за чим сам посегнуо зависило је од тога шта сам могао да контролишем у бази кода: портали када је стабло предака било непредвидиво; фиксно позиционирање када је било чисто и једноставно; померање елемента када ме ништа није спречавало; и позиционирање сидра сада,где могу. Шта год да на крају одаберете, немојте приступачност третирати као последњи корак. По мом искуству, то је тачно када се прескаче. АРИА односи, управљање фокусом, понашање тастатуре — то нису углађени. Они су део онога што чини да ствар заиста функционише. Погледајте цео изворни код у мом ГитХуб репо. Даље читање Ово су референце на које сам се стално враћао док сам радио на овоме:
Контекст слагања (МДН) „ЦСС водич за позиционирање сидра“, Хуан Диего Родригуез „Почетак рада са Поповер АПИ-јем“, Годстиме Абуру Плутајући кориснички интерфејс (флоатинг-уи.цом) ЦСС оверфлов (МДН)
