Do not consider edit mode as a history entry

2026-07-20 17:31:59 +02:00
parent 34f750beff
commit 28d22c040f
6 changed files with 93 additions and 2 deletions
@@ -75,6 +75,14 @@ Prefer separate, human-readable `.html` files over inlined HTML strings in Go. E
 - Do not inline JS in templates or merge unrelated features into one file
 - `ALT+SHIFT` is the modifier for all keyboard shortcuts — do not introduce others
 - Editor toolbar buttons use `data-action` + `data-key`; adding `data-key` auto-registers the shortcut
+- The editor is a *mode* of a page, not a destination. `history-nav.js` turns any
+  same-path `?edit` link (and the editor's CANCEL link back out) into
+  `location.replace`, and SAVE POSTs via fetch and then rewrites the entry with
+  the saved page. Net effect: an edit session never occupies a history entry of
+  its own. Links to a *different* page's editor (new page / new child) still push.
+  The save POST answers `204` + `X-Target` when the request carries
+  `X-Save-Mode: replace`, because the target may hold a `#section` anchor only
+  the server can compute and fetch drops fragments from followed redirects.
 - For mutating modals (anything that POSTs and then navigates), call `closeModal()` and then `postReplace(action, body, target)` from `page/actions.js`. Do NOT use `<form>.submit()`. Two reasons:
  1. The modal must be removed from the DOM before navigation, or the browser's bfcache snapshots it open and back-nav restores the modal.
  2. `postReplace` uses `window.location.replace` so the action + result occupy a single history entry. A naive POST → 303 → GET creates two entries, and back-nav lands on a stale pre-mutation snapshot of the same page.