Проблемы, которые Anchor Positioning не должен был решить
20.03.2026 • css
Вступление
В недавних Файерфоксе 147 и в Сафари 26 появилась поддержка Anchor Positioning. Рассматривать его во всех деталях мы в данной статье не будем и сосредоточимся на интересных кейсах применения. Достаточно знать, что этот набор свойств позволяет спозиционировать один элемент относительно другого:
.target {
anchor-name: --anchor;
}
.tooltip {
position-anchor: --anchor;
left: anchor(right);
align-self: anchor-center;
}Хорошее описание с богатыми примерами и разбором возможностей есть на doka.guide, а мы переходим к примерам, когда Anchor Positioning меняет устоявшиеся правила игры и решает доселе нерешаемые задачи.
Выпадающий попап в скроллящимся элементе
Очень старая проблема: очень давно большую часть попапов стали выносить в <body>. Это полезно, так как попап в этом случае не обрезается overflow. Посмотрим на примере выпадающего списка (саджеста):
- item 1
- item 2
- item 3
- item 4
Вынос в <body> решает проблему обрезки, но добавляет нам работы: теперь мы вынуждены следить за позицией элемента и “подтягивать” к этой позиции наш попап.
Если сделать достаточно типовой интерфейс с боковой панелью, которая скроллится по вертикали и содержит подобное поле ввода, то мы встаём перед выбором: либо делаем попап внутри скролла (и тогда он может быть обрезан областью скролла), либо сами обновляем позицию попапа по мере скролла (что не имеет красивого однострочного и беспроблемного решения на JS):
в данном примере специально замедлен механизм обновления позиции, чтобы подсветить проблему
Lorem ipsum dolor sit amet consectetur adipisicing elit. Nemo error aspernatur placeat quisquam id est nesciunt sed magnam?
- item 1
- item 2
- item 3
- item 4
И тут на помощь приходит Anchor Positioning! Браузер сам будет таскать элемент вслед за скроллом, а также сам вытащит элемент за пределы обрезки overflow. И обе перечисленные проблемы решены без единой строчки кода!
обновление позиции по скроллу может тормозить в Сафари
Lorem ipsum dolor sit amet consectetur adipisicing elit. Nemo error aspernatur placeat quisquam id est nesciunt sed magnam?
- item 1
- item 2
- item 3
- item 4
“Подпопапы”, dialog и Top Layer
Stacking Context не позволяет в произвольном месте DOM сделать попап из-за перекрытия другими элементами. overflow также ограничивает создание попапов прямо по месту.
Top layer, который пришёл вместе с модальными <dialog>, решает эти проблемы (а также сложности с z-index). В случае, если модальных диалогов несколько, то они могут показываться друг над другом.
Однако Top Layer работает только для модальных диалогов. Это значит, что если хочется открыть именно немодальный попап внутри модального, то эта концепция нам никак не поможет. Такое бывает для тех же самых тултипов или выпадающих подменю:
Anchor Positioning помогает и здесь тоже! Если оба элемента (и anchor, и элемент с position-anchor) находятся внутри Top Layer, то всё работает корректно, и мы можем спокойно “выходить” за пределы диалога:
Предупреждение о Сафари: в данный момент браузер некорректно рисует скроллбары диалога поверх элементов с position-anchor
Выделение элементов
Предположим, попапов нет вообще. Даже в этом случае может быть задача показать элементы в другом порядке, чем мы можем в условиях Stacking Context. С помощью Anchor Positioning мы можем его обойти, и показать нужные нам элементы поверх других.
Ещё один пример – это выделение активных элементов, которые могут обрезаться overflow. С помощью Anchor Positioning можно сделать аналог outline, который не будет обрезан!
Выводы
Anchor Positioning, помимо своего прямого очень крутого назначения решает и ряд других очень старых проблем, которые до сих пор можно было обойти ручным обновлением позиции “на каждый кадр” и расчётами на JS.
Я очень жду, когда можно будет спокойно использовать новое апи, потому что оно является чуть ли не единственным “бескостыльным” способом сделать некоторые фичи в более-менее сложном интерфейсе.
Давние боли CSS наконец нашли решение, не выходя за пределы CSS.
Обсудить в Telegram
