ADR-0023 · anchor Attribute and :target Highlighting
Status: Accepted
Pointing a user at a specific widget on the page ("scroll here, highlight this") could have been a JavaScript API — public widget instances, a per-widget action contract, a live catalog, a postMessage grant policy for iframe-hosted callers. That path is real but large, and buys a capability — arbitrary widget method invocation — that isn't actually needed. The required feature is highlight, which is generic DOM behavior the platform already provides: a URL fragment scrolls an element into view natively, and :target styles it, with zero script.
Decision
Add an anchor attribute on widget hosts. anchor="foo" renders as id="anchor-foo"; navigating to #anchor-foo scrolls it into view and matches :target. anchor is reserved so it never leaks into getData/render params, and it's the Markdown-reachable spelling of id — Markdown widget blocks can't carry raw HTML attributes, but they can carry params. See the Widgets guide for usage.
Why
No client JavaScript, no new API surface — ComponentElement.component stays private, no action contract, no catalog, no grant policy. Works in every SPA mode, including none (static SSR, no bundle). The visual stays the app's decision via a pseudo-class authors already know, consistent with the existing :state() styling convention. The trade-off: the highlight is sticky (lives in the URL until the next fragment navigation) rather than a self-clearing transient effect — a deliberate choice over reintroducing a JS verb and timeout.