, and .pcg-navy's background is #142440 - the SAME * rgb(20, 36, 64) those tokens are built from. Compositing rgba(20,36,64,a) over #142440 returns * #142440 for ANY alpha, so on navy this component's chrome does not merely lose contrast, it * resolves to exactly the background colour: * - --pcg-further-rule drives .pcg-further__row's border-bottom, so all 88 row separators are * mathematically invisible; * - the max-height/overflow-y scroll box below always renders a scrollbar at this list length, and * with no scrollbar-color declared the browser paints its DEFAULT light-scheme scrollbar - a dark * thumb sitting directly on the navy panel. That dark bar is what the client reported. * * A Bricks-side Custom CSS rule already re-points --pcg-further-text/-muted/-hover-bg for .pcg-navy, * but it cannot solve this: it omits --pcg-further-rule entirely, and a custom property can never * reach UA scrollbar chrome. That rule is also currently trapped inside an unclosed `:root {` block in * the Bricks field (237 opening vs 236 closing braces), so it survives only via CSS nesting - this * section's legibility must not depend on it. The token set below is therefore declared in FULL rather * than only for the missing --pcg-further-rule: the three it duplicates carry values visually identical * to the Bricks ones (#f5f5f5 vs #fff at the same alpha), so whichever rule wins the cascade the * section renders the same, and if the Bricks rule ever stops parsing this one still holds the section * together. No !important and no ID selector: the Bricks rule's (0,3,0) legitimately outranks this * (0,2,0) for the three shared tokens, and that is fine precisely because the values agree. * * Scope: .pcg-further is emitted only by [pcg_further_references], which appears in exactly one place * site-wide, so the compound .pcg-navy .pcg-further* selector can match nothing else. The light-context * defaults above are untouched, and the Berlin map's own side list (.pcg-map-list__panel, a different * component on a different page) is not addressed by any selector here. * * Colour: #f5f5f5 is the client-specified brand off-white. No alpha here is a new design decision - * each is inherited from a rule that already exists, which is why they are not all taken from the same * place: * - 0.92 / 0.60 (text, muted) agree in BOTH the light block above and the Bricks override. * - 0.14 (rule) comes from the light block above - the component's own separator strength. The Bricks * override has no opinion here because it omits this token entirely; that omission is the bug. * - 0.06 (hover-bg) is taken from the BRICKS override, NOT from the light block above, which uses * 0.05. Deliberate: matching Bricks is what makes the two rules render identically whichever wins * the cascade, per the paragraph above, and 0.05 vs 0.06 of white over navy is imperceptible. * The navy-to-paper inversion itself is the same one .pcg-map-layout already ships between its navy * default and its [data-theme="light"] block, so no new colour enters the file either. */ .pcg-navy .pcg-further { --pcg-further-text: rgba(245, 245, 245, 0.92); --pcg-further-muted: rgba(245, 245, 245, 0.60); --pcg-further-rule: rgba(245, 245, 245, 0.14); --pcg-further-hover-bg: rgba(245, 245, 245, 0.06); } /* Scroll-box chrome. Only the STANDARD scrollbar-color property is used, deliberately: it recolours * the scrollbar without converting a macOS overlay scrollbar into an always-visible classic one and * without reserving layout width, which is what a ::-webkit-scrollbar block would do (that is why * pcg-gallery.css's webkit rules are not copied here - that component HIDES its scrollbar, the opposite * intent). scrollbar-color is the thumb followed by the track: the thumb is the client-specified * #f5f5f5, the track the same off-white at the component's own rule alpha so it reads as a recess in * the navy rather than a second bright bar. scrollbar-width is deliberately NOT set - the client asked * for a colour change, not a size change. */ .pcg-navy .pcg-further__list { scrollbar-color: #f5f5f5 rgba(245, 245, 245, 0.14); } .pcg-further__list { list-style: none; margin: 0; padding: 0; /* Container-driven grid (quick task 260817-qga): the client asked for the section to fill * its own width and flow addresses to the right into columns. auto-fill + minmax reads the * column count off THIS ELEMENT's own container, not the viewport - this section is a * hand-placed Bricks element whose width the client can change without touching this file, * so a viewport media query could confidently hand 3 columns to a narrow Bricks column. The * track minimum is wrapped in min(…, 100%), never a bare px value: a bare minimum is the * exact CSS Grid "blowout" quick task 260810-1ld already shipped to a client's iPhone once * (.pcg-2col rendering ~1100px wide inside a 375px viewport) - min(…, 100%) collapses the * floor to the container's own width instead of pushing the page sideways. auto-fill, not * auto-fit, so a short 1-2 entry list still renders at one column's width instead of * stretching a single entry across the whole section. * grid-auto-flow stays the (unset) row-major default deliberately: it fills left-to-right * across a row before wrapping, matching "die Adressen füllen sich nach rechts" - the CSS * multi-column layout mode was rejected for this because it flows top-to-bottom down one * column before starting the next, the opposite of what was asked. */ display: grid; grid-template-columns: repeat(auto-fill, minmax(min(300px, 100%), 1fr)); column-gap: 32px; /* row-gap is deliberately ZERO, and written as its own longhand rather than folded into a * gap shorthand: .pcg-further__row's own padding (12px 6px) plus its border-bottom already * supply the vertical rhythm, so a positive row-gap would float each bottom rule in empty * space instead of sitting it directly on top of the next entry. Writing column-gap and * row-gap as two longhands keeps each axis independently greppable and independently * editable - a gap: shorthand would hide that they were two different decisions. */ row-gap: 0; /* Deliberately a plain fixed value, NOT a client-adjustable custom property (D-09): this * file has no root-level default block and must not gain one - the client's own Bricks * Custom Code field prints BEFORE this child-theme stylesheet, so a theme-side default * would silently beat the client's own override. The section is not allowed to grow with * every imported project - only this scrollbox does. */ max-height: 440px; overflow-y: auto; } .pcg-further__row { padding: 12px 6px; border-bottom: 1px solid var(--pcg-further-rule); /* 2px transparent LEFT border reserved for the flash state below - so lighting a row up * can never shift the row's own layout (FACT-8's precedent, applied to this new * component). */ border-left: 2px solid transparent; transition: background-color 150ms ease, border-color 150ms ease; } .pcg-further__title { display: block; font-family: 'Inter', sans-serif; font-size: 15px; font-weight: 600; color: var(--pcg-further-text); } .pcg-further__location { display: block; font-family: 'Inter', sans-serif; font-size: 13px; font-weight: 400; color: var(--pcg-further-muted); } /* Flash highlight (D-05, D-11) - triggered by berlin-map.js's revealFurtherReference() on a * map_only marker click. Starts from the component's own hover-background tint with the * accent colour on the left border, and ends at fully transparent, so the row fades back to * rest by itself with no JS cleanup needed beyond removing the class (which berlin-map.js's * setTimeout() already does). Every colour below resolves through var(--color-accent, #EE0000) * or this component's own --pcg-further-* tokens - no new hex anywhere. */ .pcg-further__row--flash { animation: pcg-further-flash 1.5s ease-out 1; } @keyframes pcg-further-flash { from { background-color: var(--pcg-further-hover-bg); border-left-color: var(--color-accent, #EE0000); } to { background-color: transparent; border-left-color: transparent; } } @media (prefers-reduced-motion: reduce) { .pcg-map-marker__dot, .pcg-map-tooltip, .pcg-map-list__item, .pcg-map-list__tab, .pcg-further__row { transition: none; } .pcg-further__row--flash { animation: none; } .pcg-further__list { scroll-behavior: auto; } } /* --------------------------------------------------------------------------- * ORTSTEIL-VERZEICHNIS — „Projekte nach Ortsteil" * * Gebaut von inc/ortsteile.php, sitzt am Ende derselben

. * * JEDE Farbe hier kommt aus den --pcg-further-*-Variablen, die dieser Block weiter oben * fuer den HELLEN und weiter unten fuer den NAVY-Kontext setzt. Kein einziger Hex-Wert, * keine eigene Variablen-Deklaration: sonst haette das Verzeichnis auf /referenzen/ * (navy) genau das Kontrastproblem, das die Debug-Sitzung vom 2026-08-18 fuer die * Zeilen darueber bereits einmal geloest hat. * --------------------------------------------------------------------------- */ .pcg-further__orte { margin-top: 1.5rem; padding-top: 1.1rem; border-top: 1px solid var(--pcg-further-rule); } .pcg-further__orte-titel { display: block; margin-bottom: 0.6rem; color: var(--pcg-further-muted); font-size: 0.82rem; letter-spacing: 0.08em; text-transform: uppercase; } .pcg-further__orte-liste { display: flex; flex-wrap: wrap; gap: 0.35rem 0.9rem; margin: 0; padding: 0; list-style: none; } /* Das Trennzeichen steht im CSS, nicht im HTML — sonst liest ein Screenreader bei jedem * Ortsteil „Mittelpunkt" mit vor. Gleiche Begruendung wie bei den Brotkrumen. * * WARUM ::after UND NICHT ::before: live nachgesehen am 2026-09-24. Als ::before auf dem * FOLGENDEN Eintrag rutschte der Punkt beim Zeilenumbruch an den Zeilenanfang — die * Liste begann dann mit „· Berlin-Prenzlauer Berg". Als ::after haengt er am * vorherigen Eintrag; `white-space: nowrap` auf dem Eintrag haelt Name und Punkt * zusammen, sodass der Punkt nie allein in eine Zeile faellt. */ .pcg-further__ortsteil { white-space: nowrap; } .pcg-further__ortsteil:not(:last-child)::after { content: "·"; margin-left: 0.9rem; color: var(--pcg-further-muted); } .pcg-further__ortsteil a { color: var(--pcg-further-text); text-decoration: none; border-bottom: 1px solid var(--pcg-further-rule); transition: border-color 0.18s ease; } .pcg-further__ortsteil a:hover, .pcg-further__ortsteil a:focus-visible { border-bottom-color: currentColor; }