There was an error while loading. Please reload this page.
Form designer guide: the decisions still open before phase 4 Part 6 described the phase 4 architecture but not what still needs deciding before any of it can be built. Those three questions were only in a private note, which is no use to anyone else. Also records what is deliberately not built - merged cells, and banded rows on a table question, which were agreed in the design conversation and never implemented.
Forms designer guide: the table question Adds Part 3c - the config shape, why columns carry a stable never-reused id, and the rule that matters most: filling in uses the LIVE columns while reading out uses ALL of them, because a value stored against a withdrawn column must still say what it was answering. Records the decisions worth not re-deriving: empty rows dropped, per-row radio group names, one CSV column per table column, a count in the submissions list, and why the Add-menu button went in last. Readers checklist extended with both places that render a submission.
Forms designer guide: the image block Adds the image block to Part 3a: its config shape, where files live, and the two questions it forces apart - who may WRITE one (analysts) versus who may READ one (a customer, only on a form that is in the catalogue, active and current). Records why the endpoint takes a field id rather than a path: it removes traversal as a category rather than filtering for it, and there is no caller-supplied string near the filesystem at all. Also why the stored value is checked in two places, why refusals are 404 and never 403, and why SVG stays refused. Notes that the image block is the SECOND legitimate exclusion from the forms-lookup type test after grid - two deliberate exceptions is a sign the rule wants teaching rather than the code bending to satisfy it.
Forms designer guide: label position, and the shared stylesheet renamed Adds Part 3b - config.label_position, why 'beside' is what produces a row of label/input pairs without a cell editor, and why the decision is made once in FormRender's ctx while the CSS needs one selector per surface. The shared stylesheet is now form-shared.css rather than form-blocks.css: label position is a property of a question, not a block, so the old name was already lying one commit in. Records that beside collapses to above below 768px, for the same reason every width goes full there, and that a single checkbox is excluded because it already draws its label beside the box.
Forms designer guide: the note block and two verification traps Adds Part 3a - what a block is, why its style is a name rather than a colour, why the block CSS is one shared stylesheet rather than a copy per surface, and why nothing had to change in the save path. Records two traps found while verifying it: - data-theme and data-theme-mode are different attributes. theme.css keys its tokens off data-theme; forms.css keys component rules off data-theme-mode. A probe that set only the latter reported every note style as identical in light and dark, which looks exactly like missing tokens. - i18n surfaces the KEY on a miss, so a key nobody added appears to a user as literal text. Scrape keys from source, and expand concatenated ones from whatever list decides the suffixes. Readers checklist extended with form-blocks.css and the language file.
Forms: a developer guide for the form designer architecture Covers the work shipped in #1813-#1819: layout as its own object, the one shared walk over a form's fields with per-surface markup, and 'is this a question' as a single decision. Written now because docs/design/form-designer.md is gitignored and exists only on one machine, and because the reasoning behind several of these decisions is not recoverable from the code alone - particularly which of the thirteen '=== section' checks were genuinely about a heading and had to stay. Also records the verification traps found the hard way: a parse checker that reported OK for a deliberately broken file, a script-tag regex that ends early on a PHP close tag, and --window-size not being the layout viewport. Cross-linked from Form-Layout-and-Grid-Developer-Guide, whose vocabulary is now corrected: what it calls 'the grid' is a table question.