[Tracking] Feature parity: rebuild interactive behaviors with WP-native primitives (not raw JS carry)

[chubes4]

North star

Turn a static HTML site into a working WordPress site with full visual AND feature parity.

Why not just carry the JS

The transform rewrites the DOM (e.g. .nav-toggle → core/button, #mobile-nav drawer deduped), so the original main.js (which targets those selectors) would break even if enqueued. Feature parity must come from rebuilding behavior with WP-native primitives, pattern by pattern.

Workstreams

• Nav hamburger → use core/navigation's built-in responsive overlay; drop the redundant dead toggle. (PR in flight)
• Forms → convert <form> to a working form block / wire a submission handler, instead of html_form_fallback preserved-but-dead markup.
• Generic custom JS behaviors → rebuild via the Interactivity API where a native block doesn't exist.
• Measurement (prereqs, separate issues): tighten acceptability of dead runtime islands; diagnose dropped-script and converted-control behavior loss; extend the visual-parity engine.

This is the umbrella; concrete slices ship as their own PRs.