Frontend interview: How do you isolate anchors in repeated components with CSS anchor-scope?

Prompt and scope

A list contains repeated cards. Each card has a trigger and an absolutely positioned tooltip. The trigger uses the same anchor-name, and the tooltip references it with position-anchor; every tooltip aligns with the last same-named anchor in the document. Design naming scope, component boundaries, fallback, and tests.

Focus on how anchor-scope limits explicit named-anchor lookup. It is not Shadow DOM isolation, and not every browser supports this Baseline 2026 feature yet.

What the interviewer is testing

• Explain why an unscoped same-name anchor can resolve by source order.
• Distinguish none, all, and a list of dashed-ident names.
• Handle implicit anchors, shadow trees, overflow fallback, and unsupported browsers.
• Turn the rule into a reusable component contract, testable DOM, and observable fallback.

Clarifying questions

1. Must a tooltip cross the card ancestor, or must it stay inside the card subtree?
2. Can components nest, use Shadow DOM, or portal the tooltip elsewhere?
3. What experience must older browsers preserve?
4. Are anchor names generated by a design system or handwritten per page?
5. Which overflow, keyboard-focus, and resize cases are required?

A 30-second answer

“The same anchor name has no visibility boundary, so a positioned element can resolve the last matching anchor in source order. I set a card container as the scope root and use anchor-scope: --card-anchor, or all when every internal name should be isolated, so the tooltip resolves within that subtree. I wrap enhancement rules in @supports and fall back to relative-container plus absolute positioning. Tests cover nesting, portals, overflow, keyboard behavior, and browsers with different support. I document the name and DOM boundary as part of the component contract.”

Step-by-step design

1. Diagnose the wrong association

anchor-name and position-anchor create an explicit association. With several same-named anchors and no scope, a positioned element can resolve the last matching anchor in source order, so repeated tooltips stack together. Inspect the computed anchor, DOM order, and containing block in DevTools before blaming size or stacking context.

2. Choose a scope boundary

Set anchor-scope on each card container to limit lookup of the chosen names to that element’s subtree. all covers anchor names in the subtree; --card-anchor limits only that name, leaving other names available for cross-component associations. Scope does not limit implicit anchors or act as general style or inheritance isolation.

.card {
  anchor-scope: --card-anchor;
}

.card__trigger {
  anchor-name: --card-anchor;
}

.card__tip {
  position: absolute;
  position-anchor: --card-anchor;
  position-area: block-end;
}

3. Define the component naming contract

Treat an anchor name as an internal component interface. The root, anchor, and positioned element must remain in the expected subtree, and arbitrary ancestors must not override the scope. For nesting, choose names per level or reset scope inside the inner component. Assert the DOM contract in component tests or Storybook.

4. Add capability detection and fallback

MDN marks anchor-scope as Baseline 2026, but older browsers may not implement it. Put enhancement rules behind @supports (anchor-scope: all). Without support, use a relative container with absolute insets, JavaScript geometry, or the existing tooltip component. Preserve focus order, accessible names, and non-obscured content in the fallback.

5. Evaluate portals, Shadow DOM, and implicit anchors

Anchor scope affects explicit named-anchor association. If a tooltip is portaled outside the card, it may leave the scope subtree; use a unique name, pass geometry, or keep the existing positioning path instead. Shadow trees have their own tree scope and require boundary tests. Do not use anchor-scope as a fix for every implicit-anchor case.

6. Test and observe

Test multiple cards, nested cards, dynamic insertion, reordering, resize, scroll, zoom, keyboard focus, and portals. Assert each tooltip’s geometry, overflow, accessibility tree, and fallback rate. Log capability detection and positioning errors without logging user input.

Model high-quality answer

“Without a scope, a same-named anchor can resolve to the last element in source order, so repeated tooltips overlap. I set anchor-scope: --card-anchor on the card root, anchor-name on the trigger, and position-anchor on the tooltip to constrain explicit lookup to the card subtree. If all internal names should be isolated, I use all; this does not affect implicit anchors or ordinary CSS inheritance. Older browsers get an @supports fallback to relative-container positioning and the existing tooltip path. I test nesting, portals, Shadow DOM, overflow, resize, keyboard focus, and reorder operations, and document the name and DOM boundaries in the component contract.”

Common mistakes

• Give every element a different anchor name → the component cannot be reused cleanly → scope the repeated name.
• Treat all as Shadow DOM → inheritance, portals, and tree scopes still differ → test lookup and style boundaries separately.
• Ignore source order → a single last-card test hides the bug → test multiple cards and reordering.
• Provide no fallback → older browsers lose tooltip placement → use @supports and the existing absolute or JavaScript path.
• Apply scope to an implicit anchor → the rule has no intended effect → confirm whether the association is explicit or implicit.

Follow-up questions and responses

When do you choose anchor-scope: all versus a named value?

Use all when every anchor name inside the component must resolve only within that card. Use --card-anchor when one name needs isolation but other names must remain available across boundaries. Test both with the component’s DOM contract.

Must the tooltip stay inside the card subtree?

No. A portal or global overlay may leave the scope subtree and lose access to the card anchor. Give the overlay a unique anchor name, pass geometry, or keep JavaScript positioning rather than forcing the overlay into the wrong DOM layer.

Is this property ready for every product?

MDN labels it Baseline 2026, while W3C CSS Anchor Positioning Level 1 remains a Working Draft. Check the target browser matrix and use @supports plus capability tests for progressive enhancement.