Website Designer in Pune: How CSS Anchor Positioning and Container Queries Are Replacing JavaScript Tooltips in 2026
A tooltip that flips from below an element to above it when it runs out of room, and correctly flips its arrow to match, used to require JavaScript — a library to calculate available space, listen for scroll and resize events, and re-render the element in the right place with the right styling. By 2026, a website designer in Pune can build that same behaviour in plain CSS, using two features that reached stable, multi-browser support this year: CSS anchor positioning and anchored container queries. If you are briefing a designer on a new site and dropdowns, tooltips, popovers or comboboxes come up, this is worth understanding, because it changes what "custom interactive design" should cost and how reliable it should be.
The Problem Anchor Positioning Solves
CSS anchor positioning lets an element (a tooltip, dropdown menu, or popover) be positioned relative to another element — its "anchor" — anywhere in the DOM, without the parent/child nesting that older CSS positioning required. You declare a position-anchor on the element you want to position, and the browser handles keeping it attached to its anchor as the page scrolls or resizes. You can also declare position-try-fallbacks, a list of alternative positions the browser should try if the preferred one would push the element off-screen — for example, flipping a tooltip from below its anchor to above it when there is not enough room underneath.
Before this feature, that resizing and repositioning logic lived in JavaScript, in libraries most developers reached for by default — often adding real weight to a page just to position a small dropdown correctly.
What Was Still Missing Until Chrome 143: Anchored Container Queries
Anchor positioning on its own solved where an element ends up, but not what it should look like once it gets there. If a tooltip flips from below its anchor to above it, its arrow, padding, or shadow direction often needs to flip too — and until this year, CSS had no way to know which fallback position was actually chosen. The element could move, but nothing could style it differently based on where it landed, so developers were back to a JavaScript workaround just for that last visual detail.
Anchored container queries, which shipped in Chrome 143, close that gap. You mark the positioned element with container-type: anchored, and then query which fallback is active with @container anchored(fallback: ...). A simplified example, adapted from Chrome's own developer documentation:
.tooltip {
position: fixed;
position-anchor: --my-anchor;
position-area: bottom;
position-try-fallbacks: flip-block;
container-type: anchored;
}
.tooltip::before { content: '▲'; } /* default: pointing up, tooltip below anchor */
@container anchored(fallback: flip-block) {
.tooltip::before {
content: '▼'; /* tooltip flipped above anchor: arrow now points down */
}
}
That is the entire logic for a self-correcting tooltip arrow, in CSS, with no scroll listener and no resize handler.
Where This Fits With the Popover API
Anchor positioning is frequently paired with the native Popover API — the popover HTML attribute that gives an element built-in show/hide behaviour, light-dismiss (closing when you click outside it), and correct stacking above other page content, all without a JavaScript modal library. Setting popover="auto" on an element means the browser handles opening one popover closing another, closing on outside click or Escape, and placing the element in the browser's dedicated top layer so it is never accidentally clipped by a parent's overflow: hidden — a specific, recurring bug in hand-built dropdown menus for years. A popover="manual" variant exists for cases where you want to control dismissal yourself, such as a set of notification toasts that should not close each other.
A dropdown menu, a filter panel, or a "more options" flyout can now combine popover for open/close behaviour with anchor positioning for placement and anchored container queries for fallback-aware styling — three problems that used to require three different approaches (typically a positioning library, custom focus-trap and outside-click logic, and manual z-index management), now solved natively and consistently across Chrome, Safari and Firefox.
There is also an accessibility argument, not just a convenience one. A native popover element gets baseline expected behaviour — focus handling, Escape-to-close, and correct exposure to assistive technology — built into the browser rather than reimplemented (and, in practice, sometimes half-implemented) by every team that builds its own dropdown from scratch. A custom JavaScript dropdown is only as accessible as the specific implementation someone wrote; a native popover starts from a baseline the browser vendor has already tested against screen readers.
A Second Worked Example: A Filter Dropdown, Not Just a Tooltip
The tooltip arrow example above is intentionally small, because it isolates exactly one problem. In a real project, the more common use case is a dropdown menu or filter panel that needs to open below its trigger button by default, flip above it if it's near the bottom of the screen, and adjust its own internal padding or max-height depending on which position it ended up in — since a dropdown squeezed above a button near the top of a mobile viewport has much less vertical room to work with than one opening comfortably below a button in the middle of the page. Anchored container queries handle exactly this: the dropdown's own @container anchored(fallback: ...) query can switch to a more compact internal layout specifically when the compressed fallback position is active, and a completely normal, roomier layout otherwise — all without any JavaScript checking the element's rendered height and switching a class name at runtime, which is how this problem was solved as recently as last year.
Browser Support: Good Enough to Ship, Not Yet Universal
As of 2026, Chrome, Safari and Firefox all ship stable support for container queries, the View Transitions API, the Popover API and anchor positioning in their current major versions, and anchor positioning specifically has reached roughly 78% global support and is still growing according to browser-support trackers. That is a reasonable bar for a lot of production use — comparable to where flexbox or CSS grid sat a few years into their own adoption curves — but it still means a website designer in Pune building for you in 2026 should be explicit about fallback behaviour for the remaining share of visitors on older browsers, particularly if your audience skews toward older Android devices, which is common for e-commerce and NGO donor traffic in India.
Migrating From an Existing JavaScript Positioning Library
If your current site already uses a library like Floating UI or the older Popper.js to position tooltips and dropdowns, there is rarely a case for ripping it out mid-project purely on principle — a working, tested implementation is worth more than a native rewrite for its own sake. The more realistic scenario is a new component, a new site, or a component you were already planning to rebuild because it has accumulated bugs. In those cases, checking whether native anchor positioning and the Popover API now cover what you need is worth doing before reaching for the library by default, because the ongoing cost difference compounds over the life of the site: fewer dependencies to update when a library ships a breaking change, less JavaScript shipped to every visitor's browser, and one less thing that can silently break when a browser update changes some edge-case behaviour the library depended on.
For a like-for-like comparison: a typical positioning-library-based tooltip component might ship 10-30KB of JavaScript (before your own component code), require wiring up scroll and resize listeners, and still need manual logic to flip an arrow icon based on final placement. The CSS-only version shown above ships zero additional JavaScript for positioning and handles resize and scroll natively, because the browser itself is doing the layout work it was already doing for every other element on the page.
Where This Shows Up Most in Practice
Three component types account for most of the real-world use of this feature combination, and they are common across almost every kind of business site a website designer in Pune builds:
- Navigation dropdowns and mega-menus — anchor positioning keeps a submenu attached correctly to its parent item even as the page scrolls or the viewport resizes, without the menu occasionally detaching or overlapping content it shouldn't.
- E-commerce filter panels — a "Filter by size / colour / price" flyout on a product listing page benefits directly: it needs to open near the button that triggered it, flip position near the edge of the screen, and close when a shopper taps elsewhere, which is exactly the
popoverplus anchor-positioning combination described above. If you are also working through a broader checkout or storefront rebuild, this is worth raising with your developer at the same time, since filter and cart-drawer components often share the same underlying positioning logic. - Form field help text and validation messages — a small explanatory tooltip anchored to a form field, which needs to flip position gracefully when the field sits near the bottom of the visible screen on a mobile device, is one of the more fiddly things to get right by hand and one of the more satisfying things to get right for free.
What This Changes About Briefing a Designer
If you are commissioning a new site or a redesign in 2026, this shift affects three practical things:
- Custom interactive components should be cheaper and more reliable than they were two years ago. A tooltip, dropdown, or filter panel that needed a JavaScript library and a developer's time to debug edge cases can now often be built with less code and fewer moving parts to break.
- Ask what your designer's fallback strategy is, not whether they "use the latest CSS." At 78% support, a meaningful minority of visitors are still on browsers without full anchor positioning support, and a competent designer should have a plan for graceful degradation rather than a broken layout.
- Performance conversations change. Fewer JavaScript dependencies for positioning logic generally means less code shipped to the browser, which plays directly into Core Web Vitals — see our related piece on why accessibility and Core Web Vitals now decide who gets hired for the broader context on why this matters for getting hired at all in 2026, not just for aesthetics.
Testing and Debugging: What to Ask For
Because this is still a relatively new part of the platform, it is fair to ask your designer or developer how they actually verify fallback behaviour before launch, rather than taking "it works" on faith. Chrome, Edge and Firefox DevTools now include dedicated inspection panels for anchor-positioned elements — you can select an anchor-positioned element and see which fallback position is currently active directly in the browser, rather than guessing from visual inspection alone. A reasonable expectation for any quote involving these components is that the designer tests each interactive element at a few realistic viewport sizes (not just desktop and one mobile breakpoint) and near-edge positions (an element anchored near the very top, bottom, left or right of the viewport) specifically, since edge cases are precisely where fallback logic earns its keep or reveals a gap.
Because Chrome, Safari and Firefox each shipped these features on slightly different timelines through 2025 and 2026, cross-browser testing during development — not just a single-browser demo — is the difference between a component that genuinely works for most visitors and one that only ever got tested in whichever browser the designer happens to use day to day.
Frequently Asked Questions
Do I need to ask specifically for "anchor positioning" in my brief?
Not by name — you should describe the interaction you want (a dropdown that never gets cut off at the edge of the screen, a tooltip that repositions itself sensibly) and let your designer or developer choose the implementation. If they mention CSS anchor positioning or the Popover API as the approach, that is a good sign they are current with 2026 standards rather than defaulting to a heavier JavaScript library out of habit.
Does this replace component libraries like Radix or Headless UI?
Not entirely. Those libraries still add accessibility behaviour, keyboard navigation, and cross-component consistency that native CSS alone does not provide. What changes is that some of the positioning logic those libraries used to have to implement in JavaScript can now be delegated to the browser, which can mean less code and fewer edge-case bugs even within a library-based build.
Is this only relevant for complex web apps, or does it matter for a simple business website?
It matters for anything with a dropdown menu, filter, tooltip, or "read more" popover — which covers most business and e-commerce sites, not just complex applications. A restaurant's mobile navigation menu and a hospital's appointment-booking filter panel both benefit from the same underlying feature.
What about visitors on older or budget Android phones, which are still common in India?
This is the honest caveat behind the 78% support figure. Anchor positioning and anchored container queries need a reasonably current browser — recent Chrome, Safari or Firefox — and a meaningful share of budget Android devices in India run older WebView versions bundled with the phone's OS rather than an auto-updating browser. A competent designer handles this with position-try-fallbacks combined with a plain, sensible default position that degrades gracefully rather than breaking, so a visitor on an older browser sees a slightly less polished but fully functional layout, not a broken one.
Will this make my website faster?
Marginally, and indirectly. The bigger effect is fewer kilobytes of JavaScript for positioning logic and one fewer runtime dependency to parse and execute, which helps Core Web Vitals metrics like Interaction to Next Paint. It is not a dramatic speed upgrade on its own, but it removes one more piece of unnecessary JavaScript from a page, and those savings add up across a full site.
How We Approach This at Govindani Infotech
We treat browser-native features like this as a first choice, not a last resort, when we scope website design and development work — fewer dependencies generally means a site that is faster to load and cheaper to maintain over its lifetime, which matters more to most clients than any single visual trend. If you are planning a new build or a redesign and want to know what a genuinely current, low-dependency implementation should look like compared to what you might currently have, our guide on what to expect from a professional website design process in 2026 covers the fuller brief, and we've also written about the View Transitions API as a companion native-CSS shift worth knowing about.
If you'd like a second opinion on whether your current site (or a quote you've received) is using dependency-heavy old patterns where a lighter native approach would now do the job, get in touch with our team and we'll take a look. It is a quick, concrete audit — pull up your site's dropdown menus and tooltips, check what they're built on, and tell you honestly whether a rebuild is worth it now or better scheduled alongside your next redesign.
Sources: