b2142ac0b0
Six conversions, one deliberately kept physical. Same method as the legends.
CONVERTED
DataTable.vue:238 .tabulator-cell border-right -> border-inline-end. A per-cell
trailing border is the COLUMN SEPARATOR between adjacent cells; in RTL the
separator has to sit on the other side or it draws on the table's outer edge.
DataTable.vue:269 .dt-actions margin-left:auto -> margin-inline-start:auto
DataTable.vue:293 .dt-close margin-left:auto -> margin-inline-start:auto
Both are "push me to the trailing end of a flex row", which is the left in RTL.
DataTable.vue:299 .dt-dl ul padding-left -> padding-inline-start. A list's
marker indent follows the reading direction.
StackLayout.vue:161,305 .stl-meta margin-left:auto -> margin-inline-start:auto
(twice: the light and dark theme blocks).
★ KEPT PHYSICAL, AND IT WOULD HAVE BEEN A REGRESSION TO CONVERT
DataTable.vue:245 '.dt:dir(rtl) … .tabulator-cell{text-align:right}'
It is already SCOPED TO :dir(rtl), so right IS the trailing edge wherever it
applies. More importantly the cells carry unicode-bidi:plaintext, which makes
`end` resolve PER CELL from that cell's own first strong character -- which is
the exact behaviour this line exists to override (English cells left-aligning
inside an rtl table and clipping at its left edge, rega L20). text-align:end
would silently undo the fix. Comment added at the site so the next reader does
not "correct" it.
No consumer overrides any of the four classes: .dt-actions, .dt-close, .dt-dl and
.stl-meta appear in no other file in library/ or plugin-designs/, so a physical
override cannot defeat the logical rule and produce a half-mirrored table.
LTR is unchanged: inline-start/inline-end resolve to left/right under dir=ltr.
check:sfc-parse PASS. 13 plugin files use DataTable, 9 use StackLayout.
library/ is the build owner's under rule 5B -- source sha to studio; rega eyeballs ar.
|
||
|---|---|---|
| .. | ||
| api | ||
| colors | ||
| components | ||
| composables | ||
| constants | ||
| data | ||
| i18n | ||
| layouts | ||
| lists | ||
| maps | ||
| packet | ||
| scripts | ||
| stores | ||
| styles | ||
| utils | ||
| vendor/cldr | ||
| 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.