Every reference to the Driver in library/ is reworded: the engineering reason
stays, the speaker and the quote go, and a decision still open reads
"provisional, pending a product decision". Comments only: each changed file
is identical after stripping comments (JavaScript, template and CSS, including
CSS comments inside the style strings shadow-DOM components inject).
Those style-string comments do ship, so several bundles change by exactly
those comment bytes.
Seven shadow-root components each carry their own copy of DX Life's
base/_globals.scss rules, because page CSS cannot reach into a shadow
root. Measured first: where the copies overlap they are byte-identical
(the Cyrillic stack 3x, strong{font-weight:500} 2x, scrollbar-gutter 2x),
so this is deduplication, not a fix.
The module exports FUNCTIONS, not strings, and the measurement forced
that: the six copies of the Cyrillic rule share one declaration but have
six different subjects (.rd-goal-card__title, .rd-h2, .rd-title,
.region-card__title, .rl-title x2). A fixed rule string would have to
pick one class and silently stop styling the other five. The caller owns
its selector; the module owns the declaration.
cyrillicHeading takes a selector LIST, not a selector. GoalCard styles
one heading class; RegionSectionCard groups two into a single rule
sharing one declaration block. A one-selector signature emits two rules
instead of one -- the same CSS to a browser, but not the same
stylesheet, and the bar here is unchanged, not equivalent.
Migrated GoalCard and RegionSectionCard. regions-dashboard's two files
port the same rules and stay with their owner; the harness records them
so that migration can run against this same baseline.
The img border-radius rule (_globals.scss:80) is documented as
deliberately NOT ported, because an invisible omission is one that gets
"fixed" later.
PROOF: internal/check-ported-globals-identical.mjs executes each
component's setup, captures the string handed to useShadowStyles and
hashes it. The emitted CSS is byte-identical across the refactor
(987d94b1cd66110d, 897d948b17b21efe, both captured from 45e31f102).
The harness's first version hashed the SOURCE of the call and was
wrong: this refactor replaces a literal with a function call, so the
source changes by construction -- a text-hash gate fails a perfect
refactor and cannot tell that from a broken one. It measured the
artifact when the property under test was the output. It failed exactly
that way on first run.
Shown capable of failing, four ways: dropping letter-spacing, a wrong
font name, 500->600, and splitting the grouped rule into two. All four
go red; restoring goes green. Components that cannot be evaluated are
reported NOT MEASURED (exit 75), never as a pass.
Applied after RENDERING the candidates side by side rather than reading a
gallery. OpenFreeMap ships a blue-toned dark style this registry never
used. At the band this product shows (30E 25N, z2.4), dark reads flat and
muddy -- near-black land against near-black water -- while fiord separates
land from sea and keeps labels legible in BOTH Latin and native script.
Endpoint verified 200 keyless first, the same bar every URL here must meet.
Note OpenFreeMap's documented '3d' style is NOT live at /styles/3d (404).
It took the three dark entries whose MAPBOX counterpart is also blue-ish:
midnight-glow (Standard@night), dusk (the entry literally says "blue
hour"), wayfinder-night (navigation-night is a blue palette). ink pairs
with near-black dark-v11 and its whole job is maximum pin contrast, so a
lighter, bluer ground would eat exactly what it exists to provide -- it
keeps dark, with a note saying so.
AND THE FALLBACK HAD TO LEARN THE THEME, which the swap alone would not
have fixed. A Standard-based profile names no registry style at all:
bootStyle() hands back the raw mapbox:// URL and the DARKNESS lives in the
config ({ basemap: { lightPreset: 'night' } }), a Mapbox-only mechanism.
maplibreStyle() collapsed every mapbox:// style to one LIGHT constant, so
flipping provider turned the dark research map into a light one -- found by
screenshotting it, not by any error: both engines mount, both paint, both
report success. Interoperability had "worked" while the product looked like
a different product. It now reads the preset the Mapbox side would have
applied, from the named entry or the boot config, so both engines tell the
same story.
VERIFIED: research map under ?provider=maplibre renders dark with the ember
dots intact and correct attribution; research dashboard under maplibre
renders the globe with all 2107 dots, greyscale choropleth, charts and
table. CAP-4 interop harness 4/4 combinations PASS. check:facet-changes-map
PASSES on mapbox (2107 -> 783 -> 2107 -> 1324, colour data-driven).
22/22 bundles, 7/7 pre, 18/18 post, browser sweep of five StackLayout
consumers and all seven studio dashboards; mapbox/maplibre search-bar and
legend geometry unchanged (56/104, NONE/58, 56/104).
NOT shipped, and filed instead: check:facet-changes-map cannot measure the
MapLibre engine at all -- it reads a private field that no MapLibre source
keeps live. Two fix attempts made it worse (one failed BOTH engines, one
called a node-side helper from page context) and were reverted; the gate is
back at HEAD and passing. The real fix re-expresses it on the public
querySourceFeatures(), which changes its reported counts and is a redesign,
not a patch.
The Driver ruled the current tiles not nice enough and asked for a
replacement FOUND online rather than authored here. Surveyed the free,
keyless MapLibre styles and measured their ocean colours: CARTO Voyager is
pale teal (#b0d0d6), OSM Americana has real blue but demo-only tile
hosting, VersaTiles Colorful has a true blue ocean (#bfd9f2) on a
maintained, production-free endpoint with 280 styled layers -- the closest
match to the Mapbox look among found styles.
One URL changed in the registry; the Mapbox side is untouched.
The Driver, correcting the first attempt: "I don't want a dark basemap, I
didn't ask for one. I asked for a spherical globe with a black background --
the galaxy, like the Mapbox map -- with blue oceans like the Mapbox map, and
the land was not to be black."
The first galaxy tinted dark tiles: black land, recoloured water -- the
night side of Earth. What was asked for is the DAY side seen from space.
So the style entry is now a normal-coloured basemap with no paint overrides
at all (mapbox standard / OpenFreeMap liberty), and the blackness lives
where it belongs: the map CONTAINER behind the sphere, a deep radial space
gradient scoped to [data-projection="globe"] so flat mercator keeps its
neutral ground.
Verified by reading the rendered screenshot before pushing: a real sphere,
blue oceans, normal land, the greyscale choropleth legible on top, black
void behind the globe, and the old caption gone.
GALAXY + MAPLIBRE. New 'galaxy' style in the shared registry -- deep-space
ground, blue oceans -- with both a mapbox and a keyless MapLibre URL, and a
paint override that is applied only if the loaded style actually has the
layer, so a miss is a silent no-op rather than a break. The dashboard now
runs provider 'maplibre' and mapStyle 'galaxy'. Reversible by two config
keys; the Mapbox path is untouched.
BOTH RESIZES RESTORED. My seven-row change had hard-capped the table's
keyhole at 7 x 26px, which read like a default and was not: nothing writes
--rd-table-rows, while the drag handles write --rd-shell-h and --rd-map-h.
So the cap was unreachable by any gesture and the Driver lost both resizes
at once, plus a grey gap where the freed pixels had no consumer.
Fixed by restoring the derivation and moving the default instead: the
keyhole is once again shell - map - bar - foot, and DEFAULTS.shellH drops
720 -> 602 (map 360 + bar 32 + 7 rows x 26 + foot 28) so the table OPENS at
seven rows while staying fully draggable. CSS fallback matched to 602.
Measured before the revert: shell handle 849 -> 731 with rows 7, table
divider map 360 -> 280 with rows 10, gap 1px after each.
Also carries the charts' frozen count column (sticky right:0 with an opaque
background, so a scrolled label cannot slide under the number) and the
ViewSelect library-index entry.
Eight of the twelve named styles resolved their MapLibre URL to
basemaps.cartocdn.com. Those are keyless today -- verified live, style JSON
and a real vector tile and a font all 200 with no token -- but CARTO's own
docs reserve the right to extend the key requirement to vector tiles. That
is a future silent outage already shipped, and the same single-point-of-
failure shape we are trying to escape by leaving the URL-restricted Mapbox
token. A dependency that is free today and gated tomorrow is a deferred one.
dark-matter -> openfreemap dark (midnight-glow, dusk, ink, wayfinder-night)
positron -> openfreemap positron (paper)
voyager -> openfreemap liberty (satellite, hybrid, wayfinder-day)
Each replacement verified before the swap: 200 keyless, zero keyed URLs in
sources/glyphs/sprite, real tiles serve. Built output now has zero CARTO
references. Embed suite 40/40 pages mount cleanly.
The header records the bar for adding a style here: keyless, commercial use
permitted, self-hostable. MapTiler and Stadia free tiers fail the second.
The page URL's ?utm_source= now outranks config/global/default in every outbound
people-group link — an iframe embedded as <page>?utm_source=agwm, a partner page
carrying its own ?utm_source, or a host page like /embed/map/?utm_source=agwm
all attribute their traffic automatically. Applied in the shared popup and both
dashboard drawer links.
