fix: stop destroying anchors that carry data-* attributes

[jonathanKingston]

What

Two related defects, both fallout from #146's split of host attributes out of the neutral core.

1. Anchors carrying data-* were destroyed, not just escaped. #146 removed data-browser-link / data-workspace-link from the escape gate (SAFE_OUTER_TAG_RE) and the sink allowlist in one commit, but only the sink got a replacement hook (sanitizeExtension). SAFE_OUTER_TAG_RE is a module-private const with no config path — yet docs/ARCHITECTURE.md told hosts they "must also widen SAFE_OUTER_TAG_RE to match", which was never actionable.

Under htmlPolicy: 'escape' / 'escape-all', a host linkDecorator emitting those attributes had its whole <a …> open tag escaped to literal text. Because </a> matches a separate arm of the same regex it survived, so the output was malformed, not merely escaped:

<p>See &lt;a href=&quot;…&quot; data-browser-link=&quot;true&quot;&gt;the docs</a> here.</p>

passthrough (the default) was unaffected, so this only bit hosts opting into escape mode. Core footnote anchors are unaffected — they don't traverse the inline escape pass.

2. The two sanitizer backends disagreed about data-*. sanitize-browser.ts claimed "identical posture to the DOMPurify backend". It wasn't:

input:      <a href="https://evil.test" data-workspace-link="true" data-anything="x">y</a>
            (allowedAttr: ['href'] — neither attr allowlisted)

DOMPURIFY : <a href="https://evil.test" data-workspace-link="true" data-anything="x">y</a>
NATIVEWALK: <a href="https://evil.test">y</a>

The DOMPurify backend never set ALLOW_DATA_ATTR: false, and DOMPurify defaults it to true, so every data-* passed regardless of the allowlist. The native walk did strict set membership. This is the real reason hosts needed a sanitizeExtension for #146's attributes — and it was invisible to a suite that runs only under jsdom + DOMPurify.

How

• src/escape.ts — the <a> arm matches any data-* attribute (value optional) by shape rather than by a list of host names, so no host's attribute names return to the neutral core.
• src/escape.ts — narrowAnchor backstops that shape test. An anchor it doesn't recognise now degrades to its allowlisted attributes instead of being escaped whole. This fixes the class, not the instance: the anchor arm was the only strict one (<code>/<em>/<strong>/<img> already take [^>]*), so any attribute the core or a host adds later would have hit the same wall.
• src/sanitize-browser.ts, src/sanitize.ts — data-* passes the sink generically, matching DOMPurify's default so the backends are genuinely interchangeable. The four now-redundant data- entries are dropped from ALLOWED_ATTR.

Reviewer notes

Security posture is unchanged or tightened. narrowAnchor rebuilds the tag from the allowlist, so unknown attributes are dropped rather than forwarded to the sink, and isSanctionedRendererTag still rejects event handlers and dangerous schemes. An unquoted <a href=javascript:…> still escapes whole (no quoted href for the scheme check to read). Tests pin all of this.

Two behaviour changes worth a look:

1. A raw prose <a href="…" style="…"> now renders as a narrowed link instead of literal text under escape. A plain raw <a href="…"> already rendered live, so this makes the outcome consistent rather than attribute-dependent — but it is a change.
2. data-* now survives the sink on the native backend. It's inert in HTML, but not on a page running htmx (data-hx-get), Alpine (data-x-on:click) or Stimulus (data-controller) — those bind to it, which hands model-authored content a live wire. No new API needed: sanitizeExtension.onElement already runs for every kept element and can re-narrow. The caveat and a recipe are documented on SanitizeExtension.

data-* is deliberately spelled twice. A regex literal in escape.ts (it tree-shakes out of entries wanting only escapeHtml; a constructed new RegExp does not, even with @__PURE__ — that cost +173 B gzipped on ./highlighters/shiki), and DATA_ATTR_NAME_SOURCE for the sink. Two copies of an attribute allowlist drifting apart is exactly what caused this bug, so data-attributes.test.ts pins them against each other behaviourally across 13 candidate names.

sanitize-backend.test.ts changed. It pinned the old stripping behaviour via a full-string strictEqual; split so the event-handler guarantee stays its own sharp assertion and the data-* change is explicit.

Follow-up this unblocks: the in-app remoteArtifactSanitizeExtension can drop its allowedAttr widening — there's a test asserting a host decorator's attributes now survive with no sanitizeExtension at all.

Verification

• npm test — 1267 tests, 0 failures
• npm run typecheck — clean
• npm run coverage:ci — 99.98% lines, baseline held (+0.00%)
• npm run size — green. ./sanitizers/browser 555 → 607 B gzipped for the new check; only that budget is bumped (555/607 verified against a clean HEAD build, so no unrelated regression is absorbed). ./highlighters/shiki returns to baseline exactly.
• ReDoS: 560 KB of adversarial near-miss input matches in ~2.4 ms, linear.

🤖 Generated with Claude Code