@spaethtech/svelte-ui 0.21.1-dev.122.60c38bb → 0.21.1-dev.124.7b5c577

package/docs/native-first-overlays.md

@@ -0,0 +1,54 @@
+# Native-first overlays — design note (Popup2 / Menu2 / Dialog2)
+
+Status: **parked for a decision** (2026-10-24). The field-shaped native-first `*2` variants
+(`Select2`, `Disclosure2`/`Accordion2`, `DatePicker2`) shipped; the **overlays** need a call on a
+cross-browser tradeoff before they're worth building, because unlike the others they can't be made
+both pixel-perfect *and* robustly no-JS today.
+
+## Why the overlays are different
+
+The shipped `*2` components lean on native elements that are **Baseline** and fully
+self-positioning: `<select>`, `<details>`, `<input type=date>`. They need no placement logic — the
+browser lays them out. `Popup`/`Menu`/`Dialog` are **anchored, top-layer overlays**: their whole job
+is to appear *next to a trigger*, flipping/ shifting against the viewport. Today's `Popup` does both
+halves in **JavaScript** — the Popover API for the top layer, and our `anchored` action for placement.
+
+A no-JS rebuild would need:
+
+1. **Toggle + top layer, no JS** — the **`popover` attribute** + a `popovertarget` button. This is
+   Baseline (2024): a `<button popovertarget="x">` opens/closes `<div popover id="x">` with
+   light-dismiss and top-layer, zero script. ✅ Solid.
+2. **Placement next to the trigger, no JS** — **CSS anchor positioning** (`anchor-name` /
+   `position-anchor` / `position-area` / `position-try`). This is where it breaks down: Chromium has
+   it, Safari shipped it recently, **Firefox is still partial/flagged**. Without it, a `popover` opens
+   but lands in its default (centered) position — not under the button.
+
+So a no-JS `Menu2` would toggle correctly everywhere but be **mispositioned in browsers lacking anchor
+positioning** — the opposite of the "pixel-perfect" goal.
+
+## Options
+
+- **A — Progressive enhancement (recommended).** Ship `Menu2`/`Popup2` with `popover` +
+  `popovertarget` for the no-JS toggle, CSS anchor positioning for placement where supported, and a
+  sane `position-area` fallback. When JS is present (hydrated), optionally enhance with the existing
+  `anchored` engine for perfect placement everywhere. Honest caveat: no-JS placement is
+  Chromium/Safari-first until Firefox catches up. Best if php-svelte's target browsers are
+  Chromium/Safari.
+- **B — Wait.** Hold the overlays until CSS anchor positioning is Baseline across the board, then the
+  no-JS story is clean everywhere. The field-shaped `*2` components already cover the common SSR form
+  needs (selects, disclosures, dates); menus/dialogs on a no-JS page are rarer.
+- **C — Dialog-only now.** `Dialog2` as a `<dialog popover>` / `popover` panel is *centered* by
+  nature (a modal doesn't anchor to a trigger), so it dodges the anchor-positioning gap. A no-JS
+  "open this dialog" via `popovertarget` works cross-browser today; the modal **backdrop + focus
+  trap** still want `showModal()` (JS) for full fidelity, but a `popover` dialog is a reasonable no-JS
+  approximation. Menu/Popup stay parked.
+
+## Recommendation
+
+Decide between **A** (build now, Chromium/Safari-first no-JS placement, documented) and **C** (do
+`Dialog2` now since it sidesteps anchoring, park `Menu2`/`Popup2` for **B**). Either way, `Menu2`
+should be built on a `Popup2` primitive the same way `Menu` is built on `Popup`, and both reuse the
+existing surface/panel classes so the open overlay stays pixel-identical to today's.
+
+The key input needed: **which browsers must php-svelte support with JS disabled?** If it's
+Chromium/Safari, go **A**. If Firefox-no-JS matters, go **B**/**C**.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@spaethtech/svelte-ui",
-  "version": "0.21.1-dev.122.60c38bb",
+  "version": "0.21.1-dev.124.7b5c577",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/spaethtech/svelte-ui.git"