| Comment: | settings: saving no longer empties the page
The description form rendered the settings page from seven fields of its own while the GET built a dozen panels, so Save returned a page with everything below the form gone — and a stray h1, because the POST also missed HideH1. Two symptoms, one cause: the same page assembled in two places. There is one builder now, and the successful save REDIRECTS, as every other settings POST already did. That leaves the saved state in one place, so the two cannot disagree again and a reload does not re-submit. The refusal path still comes back holding what the reader typed — now over the whole page rather than a fragment of it. Verified: after a save the page is byte-equivalent to the GET but for the Saved flash, with all nine panels present. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
d2368f6a92c63da190d2d4d391b97fc8 |
| User & Date: | dmestas on 2026-08-29 00:07:16.406 |
| Other Links: | manifest | tags |
|
2026-08-29
| ||
| 00:35 |
settings: save the description in place when Datastar is present
The form keeps its method and action, so without the script it posts and redirects exactly as before — the data-on:submit attribute is inert (0001 Principle 3). With the script it posts to the SAME endpoint, which answers a Datastar-Request with a patch of the panel instead of a page: the same discrimination the board's move already uses. The panel is one template block, drawn by the page and re-drawn by the save, so the two cannot drift — the fault this page had an hour ago. Its 'Saved.' now sits beside the control that saved, not at the top of a page the reader has scrolled away from, and the refusal travels with the panel as PanelError rather than as the page-wide Error. The URL is deliberately left alone on the patched path. ?saved=1 exists to carry a word across a navigation; there is no navigation here, and putting it in the address bar would make a later reload announce a save that already happened. check-in: bbd1663825 user: dmestas tags: trunk | |
| 00:26 | rfc 0009: CI — verdicts on landings, spec, premerge, runners closed check-in: 56d87626d9 user: dmestas tags: ci-rfc | |
| 00:07 |
settings: saving no longer empties the page
The description form rendered the settings page from seven fields of its own while the GET built a dozen panels, so Save returned a page with everything below the form gone — and a stray h1, because the POST also missed HideH1. Two symptoms, one cause: the same page assembled in two places. There is one builder now, and the successful save REDIRECTS, as every other settings POST already did. That leaves the saved state in one place, so the two cannot disagree again and a reload does not re-submit. The refusal path still comes back holding what the reader typed — now over the whole page rather than a fragment of it. Verified: after a save the page is byte-equivalent to the GET but for the Saved flash, with all nine panels present. check-in: d2368f6a92 user: dmestas tags: trunk | |
|
2026-08-28
| ||
| 21:08 |
a segmented control never breaks mid-way; the tools beside it move
Squeezed on a phone, the tracker's state filter dropped its last choice onto a line of its own — '99 All' under '30 Open | 69 Closed' — which reads as a stray button rather than as part of the set. The control now keeps its line whole and comes first, because it is how a reader says what they are looking at; the tool groups beside it wrap instead. The landings list is unchanged: one icon fits beside its filter, so that row still holds one line. check-in: 87f42420b7 user: dmestas tags: trunk | |