2fdfee37ac
The dashboard ships eight filter dropdowns. Seven fit on the first line and Status wraps to a second — centred, not aligned with Prayer above it. A lone centred control under a left-aligned row does not read as a layout decision, it reads as a mistake. Measured on the shipped dashboard at three viewports, line-2 left edge against line-1: 1440px 36 vs 636, six hundred pixels adrift; 1280px 16 vs 556; 1024px 33 vs 132. Never aligned at any width. The cause is `justify-content: space-evenly`, which I kept when wrapping landed here earlier today. The comment defending it is about a SCROLLER — a single line that could push its first item to a negative offset, which `safe` rescues — and that reasoning does not survive wrapping, because space-evenly distributes EACH LINE independently. Seven items distribute across the width; one item lands in the middle. flex-start keeps every line on one edge at any width. The `safe` keyword goes with it: it exists to rescue centred and space-* distributions from negative offsets, and flex-start cannot produce one, so keeping it would preserve a guard against a hazard the change removes. Now 14 / 14 / 14 at all three viewports, matching the row's own left edge, and the regenerated screenshot shows Status sitting directly beneath Prayer. Blast radius checked before editing, since this is the high-bar library zone: SearchFilterHeader is consumed by research-dashboard only. check:synced-css passes, so the two CSS copies remain byte-identical. Nine gates pass and verify:gate1 is unchanged at 13/13 against 2,107 live records. Separately noted, not fixed here: check:filter-width fails on HEAD too — verified by stashing this edit and re-running. It reports "UNMEASURED: no .filter-dropdown__trigger found in the composed tree", and that class DOES exist (FilterDropdown.vue:278), so the selector is right and the gate is not reaching the page — the same stale-navigation family as the tab-order gate fixed earlier. Left for its own commit rather than bundled into a styling change. |
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| maps | ||
| scripts | ||
| stores | ||
| styles | ||
| utils | ||
| index.js | ||
| ProfileLoader.vue | ||
| README.md | ||
library/ (@map) — the shared map template
The other half of the architecture (see ../plugin-designs/README.md):
every map in plugin-designs/<your-map>/ composes the reusable, parameterized pieces that live here.
Fix something here and every map benefits on the next build; break something here and every map
breaks — read components/WARNING.md before touching shared pieces.
| Folder | What lives there |
|---|---|
ProfileLoader.vue |
The root of every bundle: parses profile-config, loads the profile, provides the stores + config |
components/ |
Shared UI — map, legends, controls, popup (PeopleGroupDetail), tables, charts, hints (README) |
composables/ |
Shared logic — map engine (useMapInstance), provider switch, shadow-DOM styles, theming |
stores/ |
Per-instance Pinia stores (ui / map / data) — provided by ProfileLoader, injected by children |
api/ |
Data-source registry (sources.json) + fetch layer — the JAMstack runtime wiring |
colors/ |
Color sets maps opt into via profile-config.colorSet |
i18n/ |
The shared string catalogs (all maps speak the same languages) |
data/ |
Small shared datasets baked at build time (big served data lives in ../data/) |
constants/ |
Shared constants |
scripts/ |
Maintainer pipelines (posters, research) — not part of any bundle |
The rule of thumb (same as WARNING.md): custom code in your app-profile, reusable code here — and things only move from the first to the second once they've earned it.