Building "JS-Free Tooltips and Menus" with CSS Anchor Positioning — Reducing Dependencies and Maintenance Costs in Client Projects 2026

In What’s !important #12: Safari Testing, ::checkmark, HTML Anchor Positioning, and More (2026-05-29), CSS-Tricks highlighted that CSS Anchor Positioning is nearing practical viability across major browsers. Using properties such as anchor-name, position-anchor, the anchor() function, position-area, and position-try-fallbacks, positioning tooltips, popovers, dropdowns, and menus flush against reference elements and automatically shifting them when overflowing viewport edges—previously requiring JS libraries like Popper.js or Floating UI—can now be written purely and declaratively in CSS. It also pairs seamlessly with HTML's popover attribute and <dialog>, transforming how overlay UIs are engineered.

In client web development, teams have repeatedly run into issues where "heavy JS libraries were introduced solely to position tooltips and menus, ballooning dependency trees and piling on maintenance costs for version upgrades and bug fixes." Supporting web development for clients, we view this not as a matter of "whether cutting-edge CSS can be used," but as an engineering responsibility to "design and hand over accessible, easy-to-maintain overlay UIs with minimal JS dependencies, complete with fallbacks for unsupported browsers." Connecting with our native CSS adoption strategy in Using Modern Native CSS Features in Client Development (GH Media) and our evaluation criteria for new features in New CSS Features in Spring 2026 (GH Media), this article introduces our "Overlay UI and JS Library Decoupling Implementation Support" as a comprehensive custom development package.

Why rebuild overlay UI now?

In short, "positioning elements using JS libraries" and "delivering maintainable overlay UIs with minimal dependencies" are fundamentally different. Even in custom development, "shifting positioning logic to CSS, designing fallbacks, and delivering accessible interfaces" has become a core quality expectation. This enables us to guarantee architectures with reduced JS dependencies as a concrete deliverable.

What CSS Anchor Positioning enables

1. Linking elements via anchor-name and position-anchor

By applying anchor-name to a trigger element (such as a button) and specifying position-anchor on the overlay element, the two are logically coupled as "anchor and anchored element." Passing element references around in JavaScript becomes unnecessary, allowing the relationship to be handled entirely through markup and CSS.

2. Positioning via position-area and anchor()

With position-area, you can configure broad positioning like "above, below, or to the bottom right of the anchor," while the anchor() function lets you specify precise coordinate baselines such as "align top to anchor bottom." You can declare either style declaratively depending on your use case.

.tooltip-trigger {
  anchor-name: --trigger;
}

.tooltip {
  position: absolute;
  position-anchor: --trigger;
  /* アンカーの下中央に配置 */
  position-area: bottom center;
  /* 画面端ではみ出したら上に回避 */
  position-try-fallbacks: top center, bottom span-left;
}

3. Automatic edge avoidance with position-try-fallbacks

When you list fallback candidate positions sequentially in position-try-fallbacks, the browser automatically chooses the first candidate that does not overflow. The major turning point is that edge flips and offset adjustments, previously the responsibility of JavaScript, can now be accomplished through CSS declarations alone. You can also leave recalculations on resize and scroll entirely to the browser.

Five phases of client overlay UI and JS library removal implementation support

Phase 1: Inventory and assessment (1 week)

• Identifying tooltips, popovers, and menus on existing sites
• Measuring in-use JS libraries and dependency footprints
• Confirming browser support and accessibility requirements
• Deliverables: Overlay UI inventory sheet + dependency and feasibility report for library removal

Phase 2: Design (1 week)

• Distinguishing UI elements to migrate to CSS Anchor Positioning from those to retain
• Determining fallback policies (behavior in unsupported browsers)
• Integration policies with popover and <dialog>
• Deliverables: Implementation policy document + fallback design specification

Phase 3: Implementation (1–3 weeks)

• Implementing anchor binding, placement, and automatic edge avoidance
• Applying focus management, keyboard controls, and ARIA attributes
• Implementing fallbacks for unsupported browsers
• Deliverables: Implemented components + implementation standard documentation

Phase 4: Verification and handover (1 week)

• Verifying rendering and behavior across major and unsupported browsers
• Accessibility verification with screen readers and keyboards
• Deliverables: Verification report + maintenance procedure manual

Phase 5: Continuous maintenance (ongoing)

• Periodic tracking of browser support status
• Evaluating phased removal of fallbacks
• Implementing additional new overlay UI elements

Implementation standards set for custom development

Which projects need this and which do not

Six clauses to include in custom development contracts

Client ROI estimates (assuming overlay-heavy websites)

Even an initial assessment (starting from 200,000 yen) provides value in itself by visualizing how much JS dependency can be stripped from current overlay UIs. Maintenance overhead for libraries introduced solely for positioning typically compounds and takes a toll over the years.

Five common pitfalls to avoid

Pitfall 1: Failing to design fallbacks

Overlays fly off-screen in unsupported browsers. Prepare feature detection and alternative positioning in advance.

Pitfall 2: Postponing accessibility

Even if it looks functional, it remains unusable with assistive technologies. Factor in ARIA attributes and screen reader support from the outset.

Pitfall 3: Forgetting focus management

Keyboard navigation fails even after the overlay opens. Leverage the native management of popover and <dialog>.

Pitfall 4: Cramming in too many positioning candidates

Having too many candidates in position-try-fallbacks makes behavior unpredictable. Narrow them down to a realistic count and test thoroughly.

Pitfall 5: Testing on an overly narrow set of browsers

Testing only on modern browsers leads to production breakdowns. Always verify on actual target devices across all required browsers.

90-day action plan

Conclusion — Moving from library-based placement to delivering reduced dependencies

As CSS Anchor Positioning reaches practical viability, overlay UI design shifts from calculating coordinates via JavaScript libraries to declaring positioning natively in CSS. For teams supporting client web development, our Overlay UI and JS Library Removal Implementation Support serves as a core offering to deliver deliverables with minimal dependencies and maintenance overhead by moving positioning to CSS, designing fallbacks, and delivering accessible interfaces. If you are also reviewing overlays around forms, please also read Form Optimization (EFO) (GH Media).

Please feel free to reach out via our contact form if you want to remove libraries used solely for positioning, simplify tooltip and menu maintenance, or rebuild fully accessible overlays.

Sources

• What’s !important #12: Safari Testing, ::checkmark, HTML Anchor Positioning, and More（CSS-Tricks 2026-05-29）
• Using Modern Native CSS Features in Client Development (GH Media)
• New CSS Features in Spring 2026 (GH Media)
• Web Accessibility Implementation Guide (GH Media)
• Form Optimization (EFO) (GH Media)