Prompt and context
The page has links to article sections or carousel items and should highlight the current target while scrolling. CSS scroll-target-group can declare an existing navigation container as a scroll marker group, connecting fragment targets with visible content. Explain its boundary with IntersectionObserver, traditional anchors, and scroll-marker-group, then design progressive enhancement.
What interviewers assess
Interviewers look for real links that work before visual state is added. A strong answer distinguishes scroll position, focus position, and current-item styling; handles duplicate targets, dynamic content, horizontal scrolling, and reduced motion; and explains fallback when an experimental property is unavailable. One CSS declaration does not demonstrate an operable navigation system.
Questions to clarify before answering
What are the navigation targets?
Confirm whether each link targets a stable section ID, a carousel card, or a virtual-list item. Targets must be addressable by the browser and keep their meaning when the list is reordered.
How is “current” defined?
Clarify whether it means entering the viewport, crossing a threshold, receiving focus, or being the last item clicked. Scroll and focus state can differ, so one color rule cannot represent both.
Support and alternatives
List target browsers, screen readers, and keyboard requirements. scroll-target-group is experimental; traditional anchors and any required observation logic must still work independently.
30-second answer framework
“I first use semantic navigation and stable anchors for basic jumps, then declare the navigation container as a scroll-target-group so a target can receive current styling when it enters the viewport. Scroll markers do not manage focus, so I test Tab order, focus after a jump, and the return path separately. After dynamic content creates targets, I recheck the relationships. In unsupported browsers I keep normal links and add only the necessary IntersectionObserver enhancement, then test keyboard, screen reader, horizontal scrolling, and reduced-motion settings end to end.”
Step-by-step deep answer
Step 1: Create stable anchors
Generate a unique, predictable ID for each section or item and use real fragment targets in navigation links. Do not rely only on array indexes because filtering, pagination, and server rendering can change them.
Step 2: Declare the scroll marker group
In supported browsers, set scroll-target-group: auto on the table-of-contents or carousel-control container. This lets fragment links participate in the scroll-marker relationship, but it does not design focus or semantics for you.
Step 3: Separate current and focus styling
Use the current-target state or equivalent to express scroll position, and :focus-visible to express keyboard focus. When both are present, preserve contrast, understandable labels, and restrained transitions.
Step 4: Handle dynamic and multiple containers
After sections load, a carousel loops, or nested scroll containers change, recheck target uniqueness and current-item stability. Do not let one link be interpreted by multiple scroll containers; split groups when needed.
Step 5: Design fallback and verification
When the property is unsupported, normal anchors must still jump. Add IntersectionObserver only as an enhancement for current-item indication. Test keyboard, screen reader, browser back, zoom, horizontal scroll, and prefers-reduced-motion.
High-quality sample answer
I would first generate stable IDs for article sections and use real table-of-contents links so jumps work without CSS. If the target browser supports it, I would set scroll-target-group: auto on the navigation container and highlight the current target while keeping keyboard focus visible with :focus-visible. Scroll markers do not move focus into the content, so I would verify focus behavior and the return path after an intentional link activation. For infinite loading or a carousel, I would check ID uniqueness and current-item stability whenever a target is added. Unsupported browsers would retain anchors with an observer enhancement for status; I would finish with task tests on desktop, mobile, screen reader, and reduced-motion settings.
Common mistakes
- Mistake: Providing CSS state without real anchor links. → Why it fails: Unsupported browsers and assistive technology lose navigation. → Fix: Build semantic links that work independently.
- Mistake: Treating the visible item as keyboard focus. → Why it fails: A user can focus navigation without scrolling content, so states conflict. → Fix: Design current state and
:focus-visibleseparately. - Mistake: Generating target IDs from array indexes. → Why it fails: Filtering and looping loads create duplicates or drift. → Fix: Use stable business identifiers and check uniqueness after updates.
- Mistake: Shipping the experimental property as a requirement. → Why it fails: Browser support and nested-scroll behavior vary. → Fix: Keep anchors, enhance by capability, and monitor task completion.
Follow-ups and responses
Follow-up 1: Why not just use IntersectionObserver?
Observer is useful for existing-browser support or complex business thresholds; scroll-target-group can reduce this state code. They can be layered: preserve links and focus first, then compare maintenance cost.
Follow-up 2: Can a horizontal carousel and vertical table of contents share one group?
Usually not. Their scroll axes, target visibility, and keyboard models differ, so one current-item meaning becomes ambiguous. Split groups by scroll container and label them independently.
Follow-up 3: Should focus move automatically when the current section changes?
Do not move focus for passive scrolling because it interrupts keyboard users. Move focus only after an intentional navigation activation, according to the component contract, and give the screen reader a clear result.
Follow-up 4: How do you handle reduced motion?
Reduce or remove smooth scrolling and marker transitions while keeping a clear current state and focus indicator. Navigation must remain understandable without animation.