3b6cfc69b5
Groundwork for the no-selection chooser: for the seven regions to read AS
regions the moment the map loads, pins have to be colored by region, and no
existing strategy does that (_registry.js and religion.js both reference a
doxa-region.js that is not in this tree).
PLACEMENT IS NOT A PREFERENCE HERE. check:one-palette requires every hex a
consumer paints with to come from a strategy module in library/colors/,
discovered by _registry.js. That gate exists because a dashboard composable
once declared PRIVATE palettes the map had never seen — two surfaces then
disagreed about what a color meant, and one keyed color by ARRAY INDEX over a
count-sorted list, so a religion CHANGED COLOR as you filtered. A lookup table
inside my component is the exact shape that caused it.
COLOR FOLLOWS THE ENTITY, NEVER ITS RANK: the seven slots are assigned in a
fixed ALPHABETICAL order of the region's own value, deliberately not by size.
Asia has 1309 people groups today and Oceania 24; ordering by count would mean
a cross-filter that moves the counts repaints the survivors. Alphabetical is
arbitrary but STABLE, which is the property that matters.
THE PALETTE WAS VALIDATED, NOT EYEBALLED. Run through the dataviz validator and
re-stepped twice until every check passed with NO warning: lightness band PASS ·
chroma floor PASS (an earlier teal #0e7490 FAILED at 0.094, reading gray) · CVD
separation PASS at dE 8.6 deutan for the worst adjacent pair (6–8 is a floor
band that would have been legal only with secondary encoding) · normal-vision
floor PASS at dE 30.6 · contrast vs surface PASS, all seven >= 3:1 (an earlier
amber #f59e0b WARNed at 2.09:1, and the guidance is explicit that a contrast
warning is not dismissable).
Two notes on running that validator, because both cost time. Copied to a new
filename it silently does nothing and exits 0 — its CLI guard requires
process.argv[1] to end in "validate_palette.js", so a rename turns it into a
no-op that looks like a pass. And it is an ES module, so it needs a directory
with {"type":"module"} rather than a bare `node file.js`.
The hex ORDER in the file IS the validated order: the CVD check measures
ADJACENT pairs, so the legend must render regions in that same fixed order for
the result to keep holding. Noted in the file so a future reorder re-validates.
|
||
|---|---|---|
| .. | ||
| _registry.js | ||
| adoption.js | ||
| engagement.js | ||
| language-family.js | ||
| prayer-progress.js | ||
| README.md | ||
| religion.js | ||
| wagf-region.js | ||
library/colors/ — how pins get colored
Each file here is one color strategy — a way to color the map's pins (by language family, prayer
progress, religion, …). Drop a <name>.js in and it's auto-discovered; no registration.
library/colors/ a map picks a mode
┌──────────────────────────┐ ┌───────────────────────┐
│ language-family.js │ │ getColorStrategy( │
│ prayer-progress.js │──auto───► │ 'language-family') │──► colored pins
│ religion.js engagement.js│ glob │ │
│ _registry.js (the scanner)│ └───────────────────────┘
└──────────────────────────┘
shared set a single map can add/override its own in
plugin-designs/<map>/src/colors/ (that map only)
- Shared here = reused by every map. Your map's own color → put it in your bundle's
src/colors/(it merges over the shared set, for your map only — never edit the library to recolor one map). - Filename = mode key (
prayer-progress.js→prayerProgress). Files starting with_/.are skipped.
Writing or overriding a strategy? The full contract (required exports, legend wiring, checklist) is in ../../documentation/architecture/color-strategies.md.