If you have ever tried to build a give-menu, a service-times tooltip, or a nested navigation dropdown on a church website, you know the problem. The floating panel sits perfectly on desktop. On a phone, it slides off the right edge of the screen. On a tablet in landscape, it hides behind the header. The fix has always been a few hundred lines of JavaScript — a positioning library, a resize observer, a scroll listener — quietly running on every page just to keep a small menu where it belongs.
That whole layer is now optional. CSS Anchor Positioning became Baseline 2026 earlier this year, meaning it works in every current browser without a flag. For church and ministry websites, it is one of those small platform changes that removes a real source of friction — for visitors, and for whoever maintains the site next.
What it actually does
Anchor positioning lets one element declare itself the anchor, and another element position itself against it — entirely in CSS. No measurements. No JavaScript math. No getBoundingClientRect().
A minimal example. Say you have a "Give" button and a small dropdown that lists one-time giving, recurring giving, and text-to-give:
.give-button {
anchor-name: --give;
}
.give-menu {
position: absolute;
position-anchor: --give;
top: anchor(bottom);
left: anchor(left);
margin-top: 0.5rem;
}
That is the whole positioning layer. The menu sits under the button. If the button moves — because the header collapses on scroll, or the viewport resizes, or the language switches from English to Spanish and the button gets wider — the menu follows automatically. The browser handles it.
The part that matters on a phone
Church websites live on phones. Well over half of visits, on most of the sites we build, arrive from a phone held in one hand while someone is walking to their car or sitting at a lunch break. Menus that clip off the screen there are not a cosmetic problem — they are the reason a first-time guest never finishes finding your service times.
Anchor positioning ships with a companion feature called @position-try that solves this without JavaScript:
.give-menu {
position-anchor: --give;
top: anchor(bottom);
left: anchor(left);
position-try-fallbacks: --flip-right, --flip-up;
}
@position-try --flip-right {
left: auto;
right: anchor(right);
}
@position-try --flip-up {
top: auto;
bottom: anchor(top);
}
The browser tries the default position first. If the menu would clip off the right edge of the screen, it tries the second layout — anchored to the right instead of the left. If it would clip off the bottom, it tries the third — opening upward. This is the same logic that libraries like Floating UI have shipped for years, now built into the platform. It runs faster, ships zero bytes to the visitor, and never breaks when someone updates a package.
Where we are using it on ministry sites
A few places that keep coming up in our work with churches and faith-based nonprofits this year:
- The give menu. The one-tap dropdown from "Give" that lists one-time, recurring, and text-to-give options. This is the highest-value floating element on most church sites, and the one most likely to clip on a phone.
- Service-time tooltips. A small icon next to each service that opens a card with location, kids' program info, and parking notes. Anchor positioning keeps the card attached to the icon even as the visitor scrolls.
- Staff bio popovers. On a leadership page, hovering (or tapping) a staff photo can reveal a short bio card without navigating away. Combined with the native
popoverattribute, this is now a dozen lines of code total. - Language switchers. For multilingual ministries, the dropdown that lists available languages can now match the width of its trigger button using
anchor-size(width)— a small detail that makes the whole switcher feel intentional rather than bolted on.
What to keep in mind
A few practical notes from shipping this on real church sites this year.
Test the fallback path. The nice thing about @position-try is that the browser handles the flipping. The unnerving thing is that it flips in real conditions you might not see in the design file — a rotated phone, a browser with a larger default font size, a visitor who has zoomed in. Actually resize the window while the menu is open. Then rotate a phone.
Progressive enhancement still applies. About 12% of visitors globally are still on browser versions that predate full support — most of them on older Safari and Chrome on Android. A menu positioned with anchor positioning should still open in a reasonable place without it. position: absolute with a sensible default keeps everything usable.
Do not add motion for its own sake. A dropdown that appears where the visitor expects it is a small kindness. A dropdown that flies in from off-screen with a bounce is not. The point of this feature is to make navigation feel effortless — quiet in the best sense.
Church websites carry a particular weight. Someone is looking for a service time, a way to give in memory of a parent, or a phone number to reach a pastor. The technology should get out of the way. Anchor positioning is a small piece of the modern web platform that does exactly that: less code, fewer bugs, and a menu that lands where the visitor expects it.
If you are rebuilding your church or ministry site this fall and want it done with the current platform in mind, we would love to talk. Reach out here — we will bring the design, the code, and the same attention to the small details visitors quietly notice.