/* =========================================================================== * tenant_platform design tokens. * * PORTED from Qornet's _design/tokens.css (RESTRICTIONS §4 — Qornet is the * UI/UX reference). Copied whole and deliberately, including its reasoning: * the comments below record contrast ratios measured against real imagery on * a real map, and that argument is the valuable part. A token list without it * is a list of hex codes somebody will "improve" next year. * * WHAT IS DIFFERENT HERE. Qornet is one municipality, so its brand colours are * constants. This platform serves many, so anything brand-bearing — * primary/secondary colour, logo, favicon, display name — is per-tenant and * comes from `tenant_brandings`, injected at request time. The values below * are the PLATFORM DEFAULT and the fallback when a tenant sets none. * * NOT PORTED: assets/brand/. Those are Qornet Chahwan's own crest and login * artwork (chab_logo.png, municipality-logo.svg). They are one municipality's * identity, not a design system, and in this platform they are tenant data. * * Some comments below cite Qornet specifics — a GetStyles response on * `qornet:municipalities`, its brand lockup — because that is where the * measurement was taken. They are kept as provenance for the decision, not as * configuration for this platform. * ======================================================================== */ :root{ --tax-assessed:var(--c-non); --tax-unassessed:#FF3038; /* «التكليف والبناء» (colorMode.js TAX_BUILDING). Light, so the imagery reads through them; built-with-no-tax-record reuses --tax-unassessed on purpose. */ --tb-built-yes:#9ED6A0; --tb-empty-yes:#8FBCE6; --tb-empty-no:#F2D388; /* «مصاب بالتخطيط» (colorMode.js PLANNING): light orange and light green. */ --plan-hit:#F6B37F; --plan-clear:#A9DCA3; --ink-900:#0E1417; --ink-700:#2B353B; --ink-500:#5A6771; --ink-400:#8A959E; --ink-300:#B6BEC5; --s-0:#FFFFFF; --s-1:#F7F9FA; --s-2:#EDF1F3; --s-3:#DFE5E9; --s-line:#D5DDE2; --acc-700:#0B5560; --acc-600:#0E6B78; --acc-500:#128293; --acc-100:#DCEEF1; --acc-050:#F0F8F9; --sel:#E8871A; --sel-soft:#FDF0DF; /* --------------------------------------------------------------------- THE SELECTION SET'S OUTLINE. Run 16 stage 4c. Reported from the live tax map: the parcels an owner search lights up are "not clearly visible". They were drawn in --acc-500, the application's own accent, which is a mid teal — and the tax map paints its parcels by PAYMENT, so that outline was a mid-saturation line over green, orange and red fills on satellite imagery. It was present and it did not read. CHOSEN ON NUMBERS, not on taste. Against everything this line has to be seen over: --st-late #B4241F 4.57:1 satellite mid-green 5.38:1 --st-paid #15803D 3.50:1 --acc-500 (before) 3.16:1 --st-rev #B0700B 2.84:1 THE ONE PLACE IT IS WEAK IS STATED RATHER THAN HIDDEN: 1.43:1 on white and 2.42:1 on a pale roof. Every yellow bright enough to clear a red fill is weak on white; the alternative is a dark casing under the line, which is a second MapLibre layer on every vector layer in the application. The width went 2.5 → 3.5 instead, and the result was looked at on the real map over the real imagery before this was called done. IT IS NOT --sel. That is #E8871A, the SINGLE selection and the address dialog's highlight, and the two are 1.85:1 apart — close enough that one mark could be mistaken for the other, which is exactly why the set gets a token of its own rather than borrowing that one. AND IT IS NOT THE GOLD `_design/QORNET-BRAND-LOCKUP.md` REMOVED. That was rgba(182,138,53,…), a brand ornament in a colour belonging to neither the crest nor this palette. This is a map mark, at a luminance that one was never near. --------------------------------------------------------------------- */ --pick:#FFD400; /* --------------------------------------------------------------------- THE MUNICIPALITY'S OWN TWO COLOURS. Not chosen — SAMPLED, from the crest in assets/brand/municipality-logo.svg, which is the file the municipality supplied and which nothing here is allowed to restyle. The two values are the two most frequent opaque pixels in that image: 456 pixels of the red and 260 of the green, decoded from the PNG the SVG wraps. WHY THEY ARE NOT --acc-* AND MUST NEVER BE USED AS IF THEY WERE. The accent family is this SOFTWARE's colour: a link, a focus ring, a selected tool. These two are the CLIENT'S colour, and they mean "this screen belongs to the municipality" and nothing else. A button painted --brand-red would be saying that about a button. --brand-red IS CURRENTLY SPENT ON NOTHING, AND THAT IS DELIBERATE. It was the colour of the municipality's name in the compact lockup — the letterhead crop the client sent — until he looked at it and asked «why is the municipality logo label text in red??». The name is --ink-900 at every size now: the crest is where their colour belongs, and the name beside it is a heading. The token stays because it is a SAMPLE of their artwork rather than a choice somebody made, and the next thing that has to be drawn in the municipality's red should read it here rather than eyedropper the PNG again. --brand-green is spent, on the float card's hairline. CONTRAST, computed rather than eyeballed. --brand-red is 5.49:1 on --s-0 and 5.20:1 on --s-1, so it clears AA for normal text on both surfaces the lockup is ever drawn on. --brand-green is 4.97:1 and would also clear it — it is NOT used for text anyway, because green text in a municipal header reads as a STATUS ("paid", "active") in an application that already spends green on exactly that (--st-paid). It is here so that the crest's plate and the lockup's hairline can be mixed from the crest's own green instead of from a grey that happens to sit near it. --------------------------------------------------------------------- */ --brand-red:#CE1C2A; --brand-green:#138137; /* --------------------------------------------------------------------- TWO LAYERS THAT ARE DRAWN BY THIS APPLICATION RATHER THAN BY GEOSERVER. `municipalities` and `right_of_way` became vector layers so that one could carry a label and the other could be seen at all. Their colour therefore stops coming from an SLD on the server and has to be stated here — and both values are RECORDED rather than invented, so that "the map looks the same except for the thing that was asked for" is checkable. --muni-edge IS THE COLOUR IT ALREADY WAS. Read off the published style on 2026-08-25 (`GetStyles` on qornet:municipalities): a PolygonSymbolizer with no fill and `stroke #c92a2a` at width 2. The layer is unchanged except that it now says which village each ring encloses, so its edge keeps the exact hex the server was drawing. --rw-line IS ORANGE, AND SOLID, SINCE 4 SEPTEMBER 2026. Asked for by name: «حقوق المرور» "more visible, not dashed, orange colored". It was #F2B705, a deep yellow, dashed at 4.5px, and the argument for yellow — the one hue not in satellite imagery of a town — still holds; it now belongs to the expropriation line below, which is what the two easements looked like side by side: two yellows. Orange separates them. WHICH ORANGE. Not --sel (#E8871A), the single selection and the address dialog's highlight — a layer drawn in the selection colour is a layer every reader mistakes for a selection. This is #E8590C, redder by seven degrees of hue and darker: the tone the expropriation line was drawn in for years before it went yellow, so a colour this map has already been read in. 3.6:1 on white. A solid line at that contrast holds over a pale roof where the dashed one did not — 5.5px on the first instruction, 3.5px on "thinner", 2px on "more thinner", three looks the same day beside the expropriation line — and it is the same three lines of engine.js reading the same `paint` block that draw it. THERE IS NO CASING TOKEN, and it was drafted and dropped. A dark edge under the line is what VectorLabels.css's four halo passes do for a glyph, and the reason a glyph needs it is that its stems are one pixel wide. This line is two pixels. A casing would have cost a second MapLibre layer in every mount, restack and opacity pass. --------------------------------------------------------------------- */ --muni-edge:#C92A2A; --rw-line:#E8590C; /* --------------------------------------------------------------------- خطوط الاستملاك IS NOT HERE, ON PURPOSE. The expropriation line is drawn by GeoServer from styles/expropriation_lines.sld — solid, width 1.5, #FFE600 — in every page, MapLibre and Leaflet alike; no client code paints it, so a token for it would have no consumer and would only drift from the SLD. It is yellow where --rw-line is orange, so the two easements do not read as one line. Recorded here because this file is where the map's yellows are argued, not because anything reads it. (2026-09-04) --------------------------------------------------------------------- */ /* --------------------------------------------------------------------- WHAT IS ON FILE FOR A PARCEL. Three colour modes, one per kind of attachment: الصور, الملكية, المشاريع. Each is a yes/no map, so each has exactly one colour and everything else takes --c-non. THEY ARE MID-TONES AND NOT THE PASTELS THE LAND-USE FAMILY USES, and the reason is that a yes/no map is a FIND task: the reader is looking for the parcels that have something, and the pale end of the range does not separate from --c-non well enough to find anything. Measured, at engine.js's FILL_BASE of 0.72 over dark vegetation / asphalt / a bright roof, against the two floors the land-use mode already sets — ink #0E1417 against --c-non --att-photo 4.54 1.47 / 1.45 / 1.39 --att-owner 4.30 1.55 / 1.50 / 1.42 --att-project 4.27 1.56 / 1.50 / 1.43 --c-res (land use) 4.12 1.34 / 1.31 / 1.26 — so all three read BETTER than the mode they sit beside, on both counts. That is what fixed the choice: the pale versions reached 6.16 on the ink and fell to 1.07 against --c-non, and a fill you cannot pick out is a map that answers the question by not answering it. WHY THEY KEEP THE INK LABEL rather than the inverted one --st-* needed. Above 4.1:1 the parcel number reads over them, which is the whole test `labelHalo: 'dark'` exists to fail — see the contrast table in map/colorMode.js. These three sit in the land-use regime, not the payment one, and they are deliberately not darker than that. THREE HUES AND NOT ONE, though only one mode is ever on: switching between them has to LOOK like something happened, and 190°/225°/310° apart is what makes the change legible at a glance rather than a caption the reader has to check. --------------------------------------------------------------------- */ --att-photo:#46A6BC; --att-owner:#7B93D6; --att-project:#C57DB9; /* --------------------------------------------------------------------- OWNERSHIP CROSSED WITH BUILDING. The tab after «الملكية», four classes on one layer. map/ownBuilding.js carries the census and the argument for where each half of the answer comes from. TWO NEW VALUES AND TWO BORROWED, which is the whole of the scheme. --att-owner is the Ownership tab's own blue and stays the colour of "has an ownership record", so pressing from that tab to this one does not recolour the parcels it has just taught the reader to find. The class that adds a building deepens from there; the built-but-unregistered class is the one warm value; the class with neither takes --c-non, which already means "nothing on file" on this layer. ownership + building --ob-both #3F52A8 deepened --att-owner ownership, no building --att-owner #7B93D6 unchanged from that tab building, no ownership --ob-built #C58F4A the one warm value neither --c-non #BCC3C9 A 2x2 CANNOT BE DRAWN AS HUE BY LIGHTNESS, and the first attempt was exactly that: blue for ownership, dark for a building, so the four cells were a blue pair and a grey pair. Measured, the two middle cells came out at 1.13:1 against each other and dE 9 — one colour to anybody without a swatch in their hand. Four classes need four colours, which is what --st-paid and its three siblings already do on this same layer. The 2x2 STRUCTURE is carried by the ORDER of the legend rows instead, where it costs no colour and is read as words. Measured pairwise, CIELAB dE, where 20 is "plainly a different colour": both / owner 29.0 owner / built 81.2 both / built 96.4 owner / non 38.5 both / non 64.3 built / non 52.3 — worst pair 29.0, so no two of the four can be taken for each other. --ob-both IS BELOW THE INK FLOOR, AND THAT IS WHY THE MODE INVERTS ITS LABEL. The parcel number in ink #0E1417 reads 2.64:1 over it, against the 4.12 the land-use family sets as the floor; the other three clear it comfortably (6.18, 6.54, 10.42). One class under the floor is the whole case for the inverted label, and map/colorMode.js declares `labelHalo` on this mode for that reason — the same call the three attachment tabs made on 8 September, at the opposite end of the range, for their pale «None». --------------------------------------------------------------------- */ --ob-both:#3F52A8; --ob-built:#C58F4A; /* --------------------------------------------------------------------- DATAVIZ. A short sequential ramp, six steps, walked from a pale tint of the accent to --acc-700. Every step sits on the same hue as --acc-500; nothing new was invented and no second family was introduced. WHY IT IS SEPARATE FROM THE CADASTRAL COLOURS. --c-res / --c-com / --c-ind and the rest MEAN something on this map: residential, commercial, industrial. A bar drawn in --c-com would say "commercial" to anybody who has looked at the legend, about a quantity that has nothing to do with land use. The two sets must not be interchangeable, so they are not adjacent and this comment says why. SEQUENTIAL, not categorical. These are for ONE measure across several categories — a count per layer, a count per inspector — where the ramp carries rank and not identity. A chart that needs to distinguish unrelated series needs a categorical set, and there is deliberately not one here yet: the dashboard has no such chart. --------------------------------------------------------------------- */ --dv-1:#CBE6EA; --dv-2:#9FD1D9; --dv-3:#6EB6C2; --dv-4:#3F98A8; --dv-5:#197A8C; --dv-6:#0B5560; /* The groove a bar is drawn in, and the ink its value is printed in. */ --dv-track:#EDF1F3; --dv-ink:#2B353B; /* The bottom sheet's backdrop. Only ever drawn at the top detent, so it is a single value rather than a scale. */ --scrim:rgba(14,20,23,.44); --c-res:#7DA7D9; --c-com:#E8A87C; --c-ind:#9B8AA6; --c-agr:#8FBC8F; --c-pub:#6FB3B8; --c-non:#BCC3C9; /* --------------------------------------------------------------------- BUILDING USE. `buildings.bldg_use`, 11 categories over 1 184 rows, all of them filled. WHY THREE OF THE ELEVEN ARE NOT HERE. سكني, تجاري and صناعي ARE residential, commercial and industrial — the same fact the cadastral tokens were drawn for — so they are painted --c-res, --c-com and --c-ind by map/buildingUse.js and no new token is invented for them. That is the opposite of what categories.js had to do: the parcel roll has no industrial or agricultural class at all, so there --c-ind and --c-agr are palette slots carrying labels that do not match their names. Here the names are true, and the reuse is the meaning matching rather than a slot being free. WHY THE OTHER EIGHT ARE A SEPARATE FAMILY. They are a CATEGORICAL set — eleven unrelated kinds of building, no rank between them — so they must not be drawn from --dv-*, which is a sequential ramp and would say that a cemetery is more of something than a hospital. They are prefixed --bu-* rather than added to --c-* because a --c-* token is a cadastral land-use meaning that the parcels' legend also claims; a building being an embassy is not a land use and must not become one by sharing a name. THE FOUR THAT CARRY THE MAP are residential (709), mixed (200), commercial (128) and under construction (82), so those four are the ones held furthest apart: blue, ochre, orange, pale warm grey. The tail is deliberately closer together — at two and four features each they are found in the legend, which prints every class that has rows, and not by picking one shape out of a town. --bu-construction and --bu-derelict are the two neutrals on purpose: "not finished yet" and "given up on" are both absences of use, and they read as such beside nine colours that are not. --------------------------------------------------------------------- */ --bu-mixed:#C2A36B; --bu-construction:#CFC9BA; --bu-derelict:#94867A; --bu-religious:#5F9E96; --bu-government:#6E82BE; --bu-embassy:#B57FD1; --bu-hospital:#D4707A; --bu-cemetery:#7E9670; /* --------------------------------------------------------------------- STREET TYPE. `road_network.type`, 4 values over all 215 rows, none empty: Minor Road 140 · Major Road 53 · Highway 12 · Roundabout 10. WHY THIS IS A RAMP AND NOT A CATEGORICAL SET, which is the opposite of the call --bu-* made. Road classes are ORDERED — a highway carries more than a major road, which carries more than a minor one — so unrelated hues would throw away the one thing the column actually says. They walk one hue from the ink family: darker and heavier is bigger. That agrees with the width interpolation in layers/engine.js, which is the other channel carrying the same rank, and two channels saying the same thing is what makes a road hierarchy readable at a glance instead of decoded from a key. ROUNDABOUT IS NOT PART OF THE RANK and must not be read as one. It is a junction, not a class of carriageway, so it is the one hue break in the four — the accent, which is a colour this map never uses for a road. It takes the major road's WIDTH, because that is the traffic it carries; the colour is what says it is a different kind of thing. --------------------------------------------------------------------- */ --rd-highway:#2B353B; --rd-major:#5A6771; --rd-minor:#8A959E; --rd-round:#0E6B78; /* --------------------------------------------------------------------- PLANNING ZONE. `zoning.zone_type`, 7 values over all 1 945 rows, none null and none empty. Counted twice on 2026-08-06 — against the table and against the WFS response the browser actually receives: 4 1 039 3 26 30 328 1 & 4 18 3 & 4 263 2 13 2 & 4 258 = 1 945 WHY THIS FAMILY EXISTS AT ALL. The zoning layer used to be coloured by `land_use`, which holds السكنية الثانية on all 1 945 rows: one flat --c-res fill and a legend row that was true and said nothing further. `zone_type` is the only column on that table with variation in it. The note this replaces argued that inventing a --zn-* token would have put a second colour on ONE fact, and that was right about one fact. With seven, seven colours is what the legend needs. WHY NOT ONE OF THE FOUR FAMILIES ALREADY HERE. --c-* and --bu-* MEAN things: a zone painted --c-com would say "commercial" about a planning designation that claims nothing of the kind. --dv-* is SEQUENTIAL and refuses identity work in its own comment above. --id-* is DISTINCTION, for a column of unrelated NAMES where the colour means only "not its neighbour" — and zone_type is a classification with a decree behind each value and a legend key a reader can actually use, which is the opposite job. So a fifth family, namespaced, the same call --bu-* and --rd-* each made when they arrived. FOUR OF THE SEVEN ARE ONE BLUE, AND THAT IS THE FACT THE MAP IS FOR. Every combined value contains zone 4 — "1 & 4", "2 & 4", "3 & 4" — so 1 578 of 1 945 polygons, 81 %, have zone 4 over them. One hue for those four lets a reader see how far zone 4 reaches without opening the key at all, and the other three hues then read as "somewhere zone 4 does not apply", which is the other half of the same question. THE ORDER INSIDE THE BLUES IS THE PRINTED NUMERAL and nothing else: 4 alone palest, then 1 & 4, 2 & 4, 3 & 4. It looks like a rank and it is not one — a polygon in "3 & 4" is not more of anything than one in "1 & 4". It is ordered by the number the legend row already prints, so the only rank the lightness can be read as claiming is one the label states too, and a reader who reads rank into it is wrong about nothing they can act on. Zone 4 alone is palest because it is half the map: the biggest class recedes so the small ones can be found, which is rule 10 applied to a fill. THAT PALE BLUE SITS BESIDE --c-res ON THE SCREEN, because the parcels are the one layer switched on by default and --c-res is their residential class. It is a lighter, greyer blue and a token of its own, and the adjacency is not the kind of lie a reused token would be: `land_use` is السكنية الثانية on all 1 945 zoning rows, so everything painted --zn-4 IS second-residential land. Two blues that are both about residence reading as related is the palette agreeing with the data, not colliding with it. THE OTHER THREE ARE HELD APART, from the blues and from each other. 30 is the second largest at 328 and the odd one out of the seven — the only value whose `notes` carries a category code (B.1.1) rather than a decree number — so it takes a warm hue no blue is confused with. 3 and 2 are 26 and 13 polygons, small enough to lose against 1 039, so they are the two most saturated here. AN EIGHTH VALUE IS NOT IN THIS FAMILY and must not be. It takes --c-non through the `unrecorded` class in map/zoneType.js, exactly as an unknown building use and an unknown road type do. --------------------------------------------------------------------- */ --zn-4:#B9CBDD; --zn-1-4:#7C9EC2; --zn-2-4:#4F7BA6; --zn-3-4:#2A5A85; --zn-30:#C0762B; --zn-3:#4C8A57; --zn-2:#98498D; /* --------------------------------------------------------------------- DISTINCTION. Colour as identity, for a column whose values are unrelated names rather than a classification: `neighbourhood.name` (49 distinct over 50 rows) and `decree.type` (9 distinct over 10). Assigned by hashing the value — map/identity.js — so a neighbourhood keeps its colour across reloads, which an index into whatever order the API returned would not. WHY THIS IS THE THIRD FAMILY AND NOT A REUSE OF THE OTHER TWO. --dv-* is SEQUENTIAL and would claim that one neighbourhood is more of something than the next; the comment above it already refuses that job and this is the chart it was refusing it for. --c-* and --bu-* MEAN things — a neighbourhood painted --c-com would say "commercial" to anyone who has read the parcel legend, about a name that says nothing of the kind. And --l-* is the layer's own identity in the panel, so borrowing it would have two different things drawn in one colour inside one screen. TEN, and no grey. Ten is as far as a reader can hold distinct hues at once, and past it the honest answer is that the colour is only telling them "not the same as its neighbour" — which is all this family ever claims. Grey is excluded deliberately: --c-non is "unclassified" across the whole app, so a grey that meant "some particular neighbourhood" would collide with the one colour this map has already given a meaning to. An empty value takes --c-non and is a class of its own, which is why the decree with no type does not silently become one of the nine. --------------------------------------------------------------------- */ --id-1:#4E79A7; --id-2:#F28E2B; --id-3:#59A14F; --id-4:#B07AA1; --id-5:#E15759; --id-6:#76B7B2; --id-7:#EDC948; --id-8:#9C755F; --id-9:#FF9DA7; --id-10:#7C6BAF; /* --------------------------------------------------------------------- THE REFERENCE VIEW. Run 4, stage 2. Every other family on this page is a family of MEANINGS: --c-* is a land use, --rd-* is a road class, --zn-* is a planning zone, --id-* is "not its neighbour". These three are not. They are a CARTOGRAPHIC recipe — what a parcel boundary, a parcel number and a selected parcel are drawn in when the map has stopped colouring anything and is being read over imagery. The colour carries no datum at all, which is why it is namespaced apart from every family that does. Copied from the ESRI system the municipality uses today rather than invented: white boundary, yellow number with a dark halo, cyan selection. A reader moving between the two systems should not have to relearn which colour means "this is the one I clicked". TWO OF THE FIVE COLOURS ARE NOT HERE, deliberately, because the palette already holds them and they already mean the right thing: the boundary --s-0. It is white, and it is ALREADY what layers/engine.js draws a polygon layer's hairline in. Reference mode changes that line's WEIGHT and its opacity, not its colour, so inventing --ref-edge would be a second name for a value that is not a second decision. the label's halo --ink-900. The darkest thing on this page, which is exactly what a halo behind a yellow string over bright imagery has to be. The existing halo already borrows a surface token (--s-0) for the same job in VectorLabels.css, so this is the practice and not an exception to it. THE YELLOW IS NOT --id-7, which is also a yellow and is 6 % away from it. --id-7 means "one of ten colours telling names apart"; a parcel number is not one of ten of anything. Two tokens whose values nearly agree and whose meanings do not is the case the --c-* / --bu-* note argues at length, and the answer there was the same: namespace it. WHY THE SELECTION IS CYAN HERE AND ORANGE EVERYWHERE ELSE. --sel is this application's "this is the one you asked for", and it stays that in the category and payment modes — nothing about them changed. In the reference view the parcel has NO FILL, so a 3px orange ring is the only mark on an unfilled shape and reads as an annotation rather than as a selection. A semi-transparent wash fills the parcel that was clicked, which is what tells a reader WHICH shape at a glance, and cyan is what the system they already use washes it in. The edge is the lighter of the two so it reads as the boundary OF the wash rather than as a second line beside it. --ref-sel-fill is drawn semi-transparent, and the opacity is a NUMBER in layers/engine.js rather than baked into an rgba() here. Same call src/edit/drawStyle.js made and for the same reason: this page carries colour, and how much of it a fill shows is the map's decision. --------------------------------------------------------------------- */ --ref-label:#FFE04A; --ref-sel-fill:#0FC5DE; --ref-sel-edge:#7FEBFA; --st-paid:#15803D; --st-late:#B4241F; --st-rev:#B0700B; --st-exempt:#5A6771; /* Layer swatches. Assigned by theme group, in the order layer_registry yields the groups; --l-fb is the wrap-around for a group beyond the eighth. */ --l-1:#0E6B78; --l-2:#B0700B; --l-3:#3D6FA8; --l-4:#7E5AA0; --l-5:#2F7D5B; --l-6:#B4514A; --l-7:#6B7C93; --l-8:#8A6A3B; --l-fb:#5A6771; --r-sm:6px; --r-md:10px; --r-lg:14px; --r-xl:20px; --sh-1:0 1px 2px rgba(14,20,23,.06), 0 1px 3px rgba(14,20,23,.05); --sh-2:0 2px 6px rgba(14,20,23,.07), 0 8px 24px rgba(14,20,23,.09); --sh-3:0 4px 12px rgba(14,20,23,.10), 0 18px 48px rgba(14,20,23,.14); /* TAJAWAL, 4 September 2026: «change Fonts to Tajawal», asked from the field landing page. It is the face the municipality's legacy pages have always used (assets/style.css), shipped locally at /vendor/fonts/tajawal/ in seven weights, and it carries Latin as well as Arabic, so both text tokens name it and IBM Plex stays behind it as the fallback that was the face until today. --mo is NOT changed: the figures need IBM Plex Mono's tabular digits (rule 7), and a proportional face there would unalign every column. */ --ar:'Tajawal','IBM Plex Sans Arabic','Noto Sans Arabic','Segoe UI',Tahoma,sans-serif; --la:'Tajawal','IBM Plex Sans',system-ui,sans-serif; /* IBM Plex Mono has no glyph for U+066C ARABIC THOUSANDS SEPARATOR or for the Arabic unit suffixes, so a figure containing either fell through to whatever the system calls `monospace` — a different shape on every machine and a different advance width, which breaks the tabular alignment rule 7 asks for. IBM Plex Sans Arabic is already loaded and covers both, so it is named before the system fallback rather than reached by accident. */ --mo:'IBM Plex Mono','IBM Plex Sans Arabic',ui-monospace,monospace; }